user/identity is missing full Rails-style CRUD (CLI/HTTP/MCP) — no admin delete, no CLI wrapper for self-delete

Background

Surfaced while cleaning up 3 throwaway agent identities registered on staging during musehub#99 testing (ci-bot-demo-test-..., ci-bot-check2-..., fix-check-bot-...). There is currently no way to remove them.

This workspace's convention is that every muse object gets full Rails-style CRUD exposed consistently across CLI, HTTP, and MCP (singular-noun-then-verb naming — e.g. muse hub issue create/read/update/ delete, muse hub label create/list/update/delete). user/identity is an outlier against that convention.

What exists today

Server-side (musehub/api/routes/musehub/users.py):

• GET /users/{username} — read profile
• POST /users — create profile
• PUT /users/{username} — update own profile
• GET /me/export — GDPR Article 20 data export
• DELETE /me — GDPR Article 17 erasure, self-service only: scoped to claims.identity_id from the caller's own auth token. Soft-deletes the identity, hard-deletes all its registered keys, soft-deletes owned repos.

CLI (muse hub user --help): only read and update subcommands exist. No delete at all — not even wrapping the self-service DELETE /me.

Gaps

1. No CLI/MCP wrapper for the existing self-service delete. A human or agent operating entirely through first-party tooling cannot exercise their own GDPR Article 17 right to erasure — the only path today would be a raw authenticated HTTP call.
2. No admin-scoped delete-other-account capability. There is no DELETE /users/{id} (or similar) for an admin/operator to remove an account that isn't their own — e.g. cleaning up test/spam/throwaway registrations, moderation actions, or offboarding. This is the specific gap that blocked cleaning up the 3 accounts above.
3. No create/delete CLI or MCP surface at all, symmetric with the read/update that already exist.

Scope

1. Add muse hub user delete [--handle <handle>] (self, defaulting to the authenticated caller) wrapping the existing DELETE /me.
2. Design and implement an admin-scoped deletion path — likely DELETE /admin/users/{id} or similar, gated by an admin capability check (see how other admin-only mutations in this codebase gate access, if any precedent exists; if none, this needs its own design decision on what "admin" means for a MuseHub instance).
3. Wire the admin path into muse hub user delete --handle <other-handle> (or a distinct muse hub admin user delete, if admin operations deserve a separate namespace — decide and be consistent).
4. Expose whatever lands here through MCP tooling too, per the existing CLI/HTTP/MCP parity convention.
5. Decide whether muse hub user create is worth adding for symmetry, or whether account creation should stay exclusively tied to the keygen/register auth flow (likely the latter — creating a "user" outside of key registration doesn't obviously make sense for an identity-is-a-keypair system). Document the decision either way so this doesn't get re-litigated.

Acceptance criteria

• A human can delete their own account through muse hub user delete without touching raw HTTP.
• An admin can delete a different account through some documented, capability-gated path.
• Both paths are documented in muse/docs/agent-guide.md's Gitism Glossary / hub command reference, consistent with every other resource.