muse reset's dirty-workdir guard suggests --merge/--autoshelf, neither of which exist on muse reset

Found while investigating an incident where an agent passed muse reset --hard --force and discarded uncommitted working-tree changes (later fully recovered from the object store — a separate commit had already captured the same content). The --force override itself was correct, intentional behavior on the guard's part; this ticket is about a different, smaller bug found during that investigation.

Confirmed: muse/cli/guard.py's require_clean_workdir() prints remediation hints when it blocks a dirty-workdir operation:

muse reset --merge         — carry changes forward (three-way merge)
muse reset --autoshelf     — shelf automatically, switch, pop on arrival

But muse/cli/commands/reset.py's register() only defines ref, --hard, --soft, --force, --dry-run/-n, --json/-j. Neither --merge nor --autoshelf exists on muse reset — those flags are real on checkout/merge/switch (checkout.py:623, merge.py:1417, switch.py:180), and the guard message is shared/generic across all of them without checking which command is actually invoking it.

Reproduced: running the tool's own suggested remediation, muse reset --autoshelf, fails immediately with an argparse "unrecognized arguments" error — the exact opposite of a safe recovery path.

Suggested fix: either (a) make the guard message context-aware (accept a parameter for which remediation flags actually apply to the calling command), or (b) simplest: reset's specific call site should print reset-appropriate remediation only (muse shelf save first, then retry; or --force if you're sure) instead of the generic three-command hint meant for checkout/merge/switch.

Not data-integrity-affecting on its own — the guard still correctly blocks the dangerous operation either way. It's a UX/correctness bug: the tool's own advice for the one command that most needs a working recovery path is currently broken.