fix(admin): revoke reaches an admin who created another admin

[42-v]

POST /admin/admins/{id}/revoke could not revoke any admin who had opened another account. The account survived, and so did its live sessions.

auth.admin_users.created_by referenced its own table with no ON DELETE clause, so NO ACTION applied and deleting a row another row still named raised 23503. AdminUserRepo.Revoke is a bare DELETE, so the whole statement failed. admin_sessions cascades — but only when the parent delete succeeds, and it did not, so the sessions the revoke exists to kill stayed open.

created_by is set on every create and migration 016 raises when it is null once any admin exists, so the admin graph is a tree. The bootstrap super_admin became unrevokable the moment it opened one other account — which is the first thing an operator does.

Why this outranks an ordinary 500: revoke is the only containment lever the admin plane has. router.go:125-128 is the entire surface — list, create, revoke. No admin update, no admin lock, no per-admin-session revoke. An admin whose credentials were known to be compromised could not be stopped at all.

The fix

Migration 042 makes the constraint ON DELETE SET NULL. Deliberately not CASCADE — that would delete the revoked admin's entire created subtree, so revoking one compromised account would silently remove every account it had ever opened. Worse than the bug.

The handler now:

• reads the row before deleting, and writes the old created_by into the audit metadata, so "who authorized this account" survives the SET NULL
• audits the failure path. Returning 500 before the audit call left no trace of the one event an operator most needs to see: a containment attempt that did not work.

Coverage

The existing repo test passes on the unfixed code because it only ever revokes a leaf (target.CreatedBy = admin.ID, then revokes the target). The new test revokes upward and asserts all three properties:

Property	Why it matters
the creator is gone	the revoke actually happened
its sessions cascaded to zero	the cascade only runs if the parent delete succeeds
the child survives with created_by cleared	SET NULL, not CASCADE

Removing the migration fails it with the defect named. docs/admin-gateway.md asserted the opposite of the tree's behaviour and is corrected; UPGRADING.md carries the migration count and what the upgrade does.

Verified: go build ./..., go vet, go test -race ./internal/adminapi/, tests/spec + tests/compliance green, golangci-lint 0 issues on a cleaned cache.

fix(admin): revoke reaches an admin who created another admin