Story 2723: Billing authority, and the seat / admin lifecycle refusals

The money rail exists. Story-2711 created the tenant, Story-2714 built the payment substrate, Story-2715 added grant codes, Story-2719 shipped the firm's month-one checkout and its e-mandate. Every one of those routes was gated with settings:write. This Story asks who is allowed to touch any of it - and closes the seat and admin-handover rules that make the answer stable over time. Out of scope and untouched: the renewal job, statements, and ledger emission internals (Story-2721, running in parallel).

Why settings:write was the wrong gate

1. Where things live

2. The gate is a dependency, not a rule copied per route

require_billing_authority could have been require_permission("billing:manage") and it would have refused correctly. It is not, for one reason: SB-19 requires the refusal to be recorded, and a raised 403 rolls its own transaction back. A Firm Admin asking "who tried to change our seats?" is asking their audit log, not our CloudWatch.

So the dep writes one committed firm_billing.access_denied row in its own transaction, then re-raises - the same shape the staff unit-economics gate has used since Story-2543 (CL-12). The membership lookup runs under a transient staff GUC and the GUCs then flip to the refused caller's own firm context, so the row is stamped actor_kind='firm_user' and the audit_log insert policy holds honestly. An org-less caller named no tenant (Bug-2568), so there is no firm trail to write to and the structured log is the only record - writing into a firm the caller never selected would be a write side effect under no org.

What is now Firm-Admin-only

The reads move too, and that is D15, not caution: Members never see amounts. A mandate ceiling, a seat price, and a receipt total are amounts. The two 410 Gone credit stubs in seats_and_billing/router.py stay ungated - a deprecation shape is not data, and gating a tombstone only changes which error a stale client sees.

3. Seats: a seat is committed when the invite is sent

load_seat_state returns three numbers in one round-trip: the seat limit, the active members, and the open invites. Counting only members would let a Firm Admin mint ten invites into three seats and discover the problem when the tenth colleague clicks their link - a refusal aimed at the wrong person, after the seat was promised. So SB-27 refuses at minting time, names both counts, and carries remedy: "increase_seats" so the UI can offer the way out instead of a dead end.

SB-28 is the mirror image and deliberately produces one refusal with both numbers. A Firm Admin cutting three seats to two is over the member count and under the plan floor simultaneously; being told about one, fixing it, and hitting the other is two round-trips through the same wall.

PATCH /app/firm/seats  {"seats": 2}
422 pramaan.billing.seats_below_floor
    "This firm cannot hold 2 seat(s): 3 member(s) are active, and the plan's
     minimum is 3 seat(s). Remove members first, or keep at least the minimum."
    details: {requested_seats, active_members, open_invites, min_seats, minimum_allowed_seats}

The bug the seat route would have had

4. SB-29: stepping down is a handover, not a prohibition

Two guards already existed and both were too blunt. cannot_deactivate_self refused a Firm Admin leaving under any circumstances, and cannot_demote_self refused a Firm Admin lowering their own role under any circumstances. A founder who hired a partner could never hand over and leave.

The rule that was actually meant is the firm always has someone who can pay its bill. Both self-guards are replaced by the last-admin check that was already there for the other-target case: refused while you are the only Firm Admin, allowed the moment a second one exists. The refusal message names the way out.

The two retired codes are deleted, not aliased: cannot_deactivate_self and cannot_demote_self no longer exist anywhere, and the integration tests that asserted them now assert the handover behaviour instead.

5. SB-49: removal is already immediate - this locks it in

6. SB-53: visible, never refused, and it costs no new write

One login shared by a whole chamber is how a three-seat firm does six people's work. The RFD does not refuse it - refusing on a heuristic would block a lawyer mid-matter over a coincidence (two offices, a phone, a VPN), and being wrong costs far more than the leakage. The decision is to make it visible.

The evidence substrate is deliberately not a new table. Every billable intake already writes a document.created audit row; this Story stamps the caller's Clerk session id (sid) into that row's metadata. Counting distinct session ids over a window against ix_audit_log_actor_created is then one query, on the path that already costs money. No sightings table, no per-request write, no sweep.

threshold  4 distinct sessions      (laptop + phone + one more is still ordinary)
window     60 minutes
action     member.concurrent_sessions_flagged   category=access_security  area=firm
dedupe     one row per member per window - a genuinely shared login must not bury
           its own firm's audit log under the evidence of the sharing

Placement is the billable path and not every request, because the risk being watched is seat sharing, and seat sharing shows up as spending from many places under one name. A login that reads is not the concern - reading never locks (D15) and reading is not billed. sid authorizes nothing; it is documented in docs/contracts/clerk-jwt-contract.md as read-for-counting only, and a token without it still works - the count is simply not taken.

7. Executable acceptance

Nothing is mocked. The authority scenarios go through the real FastAPI app over ASGI so the dependency graph - Clerk claims, the permission matrix, the RLS session, the gate - is the one production wires. Story-2723 adds no outbound call, so there is no provider to simulate.

8. Review gate

9. Planted negatives (no green counts until it has been red)

SB-19 is the one scenario whose refusal comes from the permission matrix rather than a branch in this repo's code; its red proof is the same edit reviewers can make - remove BillingAuthorityDep from any route in the table above and the scenario's every attempt is refused step fails on that surface.