fix: edit --create follow-ups (folder/title selectors, created/restored output)

[gitkeniwo]

Follow-ups from testing the 0.6.4 cheat-style lookup work.

Folder/title selectors

snip edit scratch/notes --create files a snippet under scratch and finds it again on the next run, but snip scratch/notes and snip show scratch/notes reported not found. Library::resolve_snippet now falls back to folder/title, split at the last slash, after package path, UUID prefix, and exact title:

• A title that itself contains a slash still wins.
• A duplicate folder/title is the usual ambiguity error, with candidates listed.
• A missing folder/title stays a not_found with no hint, so --create still creates.

The selector help text, the agent skill, and snip-query(1) document the new form. snip-query(1) also still called ambiguous titles "conflicts", which the 0.6.4 docs fix missed.

Mutation output

print_mutation hardcoded updated:, including for snip create and snip restore. It now takes the action:

Command	Human first line
snip create / snip edit --create (new)	created:
snip restore	restored:
edits	updated:

snip edit --create also printed unchanged: <id> when the editor saved nothing, although the new snippet exists. It now prints created:. JSON output is unchanged.

Verification

• cargo fmt --check, both clippy configs with -D warnings, and the three generator --checks pass.
• cargo test --all-targets: 537 passed, 0 failed.
• New unit tests cover resolving folder/title, exact-title precedence, and a hintless not_found. A new CLI test covers show Two/Duplicate and the created/updated/restored labels.
• Checked by hand under a pty with stub editors: create with no save, create with a save, re-edit, bare snip work/notes, and show deep/nested/thing.