AccessKeysService::revoke() updated status/revoked_at/revoked_reason and
wrote an audit log, but never touched the storage agent — unlike delete(),
it didn't push iam_delete. A "revoked" key kept authenticating against
SeaweedFS forever, since s3.json was never updated. There's no disable/
suspend command on the agent side (only iam_create/iam_delete), so revoke
now pushes iam_delete exactly like delete() does; our record stays around
as `revoked` instead of being removed, preserving the audit trail.

Also:
- AccessKeysPerspective model + its transformer now expose `name`, matching
  the base AccessKeys transformer from the previous commit.
- docs/ui/ui-specification.md §6: documents the name field, a full
  bucket-ACL picker design for the create form (every key created through
  the dashboard has always gotten unrestricted access to every bucket, since
  the create form never sends bucket_acls at all), and a new §6.3 explaining
  why role/ACL editing must not be exposed in the UI (no iam_update exists).
- docs/ui/updates/2026-07-05-access-key-name-and-bucket-acls.md: the "why"
  note for the panel team.