# `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.