fix(git): revoke access for banned relay members

[jmecom]

This change rechecks the durable community ban in the shared Git HTTP authentication path for advertise, fetch, and push requests. A banned member is denied even if repository-channel membership still exists, and restriction lookup errors fail closed.

The additional database lookup happens on every Git HTTP request so access revocation does not depend on stale session state.

The check also cascades to the NIP-OA owner. Git accepts NIP-OA attestations on the NIP-98 token, so an agent key can act for its owner — without the cascade, a banned human would keep clone and push access through any agent key. This mirrors the NIP-42 gate in handlers::auth: either principal's ban denies the request.

The check runs inside the GitAuth extractor, so all three Git routes inherit it.

Testing

• git diff --check origin/main...codex/security-ban-revokes-git
• Rebased onto origin/main at 5c98932
• cargo test -p buzz-relay --lib sec005_read_gate_tests: 8 passed, 7 ignored (Postgres)
• cargo clippy -p buzz-relay --all-targets -- -D warnings and cargo fmt --check: clean

Pure tests cover the decision table (agent ban, inherited owner ban, no attestation). Postgres-gated tests cover the wiring: the real ban row, a live compute_auth_tag attestation, and the 503 fail-closed path.

Not yet verified: the three Postgres-gated tests compile and skip but have not been run — no local Postgres, and CI does not run --ignored. They need cargo test -p buzz-relay --lib sec005_read_gate_tests -- --ignored against a migrated dev database.

Originating Buzz thread: buzz://message?channel=3928fe05-df61-4b5d-b9c7-d623b9b10ea1&id=3c6c02312f763fbe0d2bfc33a6c1a362f91d0354f3d18b039cf7a0558c1439d1

[elifoster-block]

Added a check to ensure that banning a human must also revoke their agents

[wesbillman]

Security review by Carl, acting on Wes’s behalf.

I found no blocking issue at head 129d09da16723a5cb06b9288ca2d1b353ff95d0b.

The ban lookup is in the shared GitAuth extractor, so advertise, fetch, and push all re-read tenant-scoped durable restriction state. Restriction-store failures deny with 503. Direct bans deny with 403, and a cryptographically verified NIP-OA owner is also checked, preventing a banned owner from retaining access through an attested agent.

I also traced the attestation path: the auth tag embedded in the already-verified NIP-98 event is preferred, duplicate event auth tags are rejected, and verify_auth_tag binds the owner signature to the authenticated agent pubkey. Membership and ban cascade therefore resolve the same proven relationship.

The exact-head CI suite is green. The three new ignored Postgres wiring tests were not run because no migrated local Postgres fixture is available; they compile in CI, while the decision logic has non-ignored unit coverage. I consider that a validation caveat, not a merge blocker given the direct wiring review and existing green relay/backend integration suites.