Rename a credential’s Service (UID) after creation

[arimxyer]

Splitting this out of #89 as a design discussion for a future feature.

The ask

Today a credential’s Service (UID) is fixed once created — it can’t be edited in the TUI (the field is read-only in the edit form) or via update (no rename flag). Users want to rename it, e.g. after a typo or to reorganize.

Why it’s not a simple field edit

The Service is the vault’s primary key, so "renaming" is really a re-key operation: add the credential under the new key and remove the old one, while preserving everything attached to it. That’s why it was deferred rather than bundled with the case-insensitive sort fix (shipped in v0.19.0).

Things to work out

• CLI shape — a dedicated pass-cli rename <old> <new> (a.k.a. mv), or a --service/--rename flag on update? A separate verb reads more clearly and keeps update’s field semantics clean.
• Preserve metadata — created-at, usage timestamps/counts, categories, URL, notes, TOTP must carry over unchanged; only the key changes.
• Collision handling — refuse (fail-closed) if the new Service already exists, rather than overwrite.
• TUI — enable the Service field in the edit form (routing to the rename path), or a separate keybinding/action? The edit form currently disables it deliberately.
• Sync — it’s a delete + add against the single encrypted vault file, so it’s one push like any other write; no special handling expected, but worth confirming there’s no conflict edge case.
• Validation — same rules as add for the new name.

Scope thoughts

Probably a small, self-contained feature: a vault-layer Rename(old, new) that does the keyed move atomically in-memory before save, a thin rename command, and the TUI wiring.

Feedback welcome on the command shape and TUI approach before anyone picks it up.

Originally requested by @0pLuS0 in #89.