carlos / platform Public

mail: the nine email doors go through the role gate, three of them closed

Merging main brought service principals (#227) into this branch, and with
it the rule that every /api/cli/ door names at registration which service
roles may reach it. The email family predated that and registered with
plain mux.HandleFunc, so all nine doors 404'd on the merge result:
apiPrincipalAccount refuses outright when the principal is not in the
request context, and only cliRoute puts it there. The failure was total
and silent on the branch alone — the branch has no cliRoute to bypass.

Six doors take Allow(Admin), matching the store family verb for verb:
declare, ensure, verify, enable, rotate and status all move an account's
backend estate, and enable mints a path-scoped IAM user exactly as store
grant does.

Three are closed to every role, admin included, each for its own reason:

  - credentials create is the only door in the API that hands a plaintext
    sending secret back to its caller. Store seals its secret into config
    and keeps no key to open it; this one cannot, because a standalone
    credential exists to be copied into an off-platform MTA. A service
    credential reaching it would turn "may deploy this app" into "may
    send as this account's domain", with no delivery step and no expiry.
  - credentials revoke closes with it, as the services family does.
  - pause already resolves an address against CARLOS_MAIL_OPERATORS,
    which no service principal can hold, so naming a role would be a
    registration that lies about who gets in. It raises the daily cap in
    the same request besides — an authority grant, not a runtime toggle.

All three are pinned at the intent level (mintDoors, policyDoors) as well
as in closedDoors, so reopening one takes an edit that argues with the
words beside it.

Gate green: 31 packages, vet clean, gofmt clean, all three cross targets.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>