feat(server): add admin-only RenameAccount RPC (RIG-5151)

[rigel-mintaka]

Summary

Add an admin-only RenameAccount RPC. It renames a user or an agent in place, following DL-271: rename in place at both tiers, and a freed handle may be reclaimed.

Why

Matt ruled B on handle renames: an admin RPC now, with user self-rename later as its own design (RIG-4581). Before this there was no rename write path; only tests renamed handles, with raw SQL.

Change

• Store.RenameHandle changes these in one tenant transaction:

  • account_handles.handle (the resolution key) and accounts.handle (the display copy);
  • every same-owner DM whose name is built from the handle (agent-agent and owner-agent), re-keyed in place with ids and history kept;
  • the agent's home channel, and a manager's coordination channel (with the existing collision suffix).

  A taken handle is ErrConflict. Locks: the owner's DM lock, then the coordination lock. A DM converted to a channel after the scan is skipped.

• OpenDM reads both handles under the DM lock. The coordination reconcile re-reads the manager handle after taking its lock. So a queued open or reconcile cannot bring back the old name.

• CompassService.RenameAccount is classified adminOnly in the AdminGate. It resolves the account the way IssueToken does. Errors:

  Case	Code
  empty or bad grammar, or a qualified new_handle	InvalidArgument
  unknown account	NotFound
  handle taken	AlreadyExists
  system account	PermissionDenied
  bootstrap admin or its root supervisor (startup finds them by handle)	FailedPrecondition

  It returns the new address, owner-qualified for agents. After commit it publishes AccountChanged, plus a ChannelChanged for each renamed channel.

• Proto, generated Go and TS clients, and the product spec are updated (new requirement and scenarios; admin-only lists).

Verification

• New and updated pgtests pass:
  • rename at both tiers, including the display column;
  • reclaim;
  • collisions per tier, with rollback;
  • an invalid handle or unknown id;
  • a rename to the same handle is a no-op;
  • DM re-key: agent-agent, owner-agent, an owner whose handle matches one of its agents, and a reclaimed handle not resuming old history;
  • a DM converted after the scan is skipped;
  • the home channel is renamed;
  • the manager keeps a single coordination channel, including a reconcile queued behind the rename;
  • handler codes and protected accounts;
  • published AccountChanged and ChannelChanged for home, coordination and DM channels;
  • AdminGate classification.
• Mutations, each killed:
  • conflict mapping, display update, system guard, agent qualification, gate;
  • DM re-key, owner-agent scope, publish, admin protection, root protection;
  • the actual-party filter.
• The full internal/comms, internal/store, server and internal/auth pgtest packages pass.
• golangci-lint reports 0 issues on both tag sets. Nilaway, proto lint/drift and sqlc-drift are clean, and rumdl is clean on the spec.
• Review loop: round 1 found 1 high and 2 medium; round 2 found 2 medium; round 3 found 1 medium and 1 low. All are fixed. The final interdiff found 0/0/0.

Refs RIG-5151.

Ledger-impact: none (implements DL-271's rename policy; no new decision).

[trunk-io]

😎 This pull request was merged.

[linear-code]

RIG-5151

[rigel-mintaka]

Review loop at head cfad468. Round 1 found 1 high and 2 medium: DM history reachable through a reclaimed handle, no AccountChanged event, and built-in identities renamable. Round 2 found 2 medium: a race with DM-to-channel conversion, and stale home and coordination channel names. Round 3 found 1 medium and 1 low: an owner-handle overlap re-keying an agent-agent DM, and a missing coordination event test. All are fixed with regression tests and mutation checks. The final interdiff review found 0/0/0.

[github-actions]

Compass engineering docs preview: https://compass-repo-rig-5151-rename.compass-eng-docs.pages.dev

Deployed from compass-repo/rig-5151-rename-account at cfad468.

Changed pages:

• docs/specs/product/compass.md