fix: make reset work like git restore (and rename it to restore)

[vinceblock99]

Bug

atomic reset <file> was unusable for its most common case. status tells you to run it to discard changes, but it then refused with Cannot reset: there are uncommitted changes and told you to record first — even though discarding uncommitted edits is reset's entire job. The guard also checked the whole tree, so an unrelated dirty file blocked resetting the file you actually named. On top of that it surfaced as Internal error (looks like a bug, not a user action).

Why

atomic reset is effectively git restore: restore the working copy to the last recorded state. Naming a file is explicit consent to discard it — there's nothing to guard against.

Changes

Behavior (commit 1)

• Named-file reset works without --force; only a whole-tree reset (no paths) still requires it.
• Guard now returns a user-level error (RequiresForce, exit 1), not Internal error.
• reset <added-file> untracks it but keeps it on disk, so status stops reporting a phantom "new file".
• Partial reset no longer claims "working copy is clean" when other paths are dirty.
• --view was silently half-switching views (left stale content); first made it fail fast.

Rename (commit 2)

• Renames the command to restore (its real semantics = git restore); reset stays as a permanent hidden alias, so existing usage/scripts keep working.
• Removes --view entirely — switching views is atomic view switch.
• Updates output verbs, the status hint, and the guard error text to "restore".

Adds unit + binary-driven integration tests for all of the above. Docs (atomic-docs) follow in a separate PR.

[leefaus]

this looks good. 🚢