feat(sending): compose ramp with protection gate

[jiashuoz]

Summary

B4 of the sending-protection plan (Task 4). Stacked on #990 — base is feat/sending-protection-gate, not main, because this slice needs B3's Gate. Review #990 first; this PR's diff is only the ramp composition.

The ramp and the budget answer different questions — has this domain earned this volume yet vs. has this account or the platform exposed SES enough today — and this makes one transaction answer both, most restrictive winning.

One lock order for the ramp. The store used three: Reserve took domain → scope → reservation → counter, Confirm took reservation → counter → scope, Release took reservation → counter. Three orders over four keys is a deadlock waiting for traffic, and it becomes unavoidable once the gate composes both ledgers into one transaction — that transaction already holds highly contended global budget counters when it reaches the ramp. internal/sendramp/tx.go now holds the single order and the pool-owning methods are thin wrappers, so there is no second implementation to drift.

Composition (internal/sendingpolicy/ramp.go):

• Probation is the ramp's answer now. Shared-relay traffic stays probationary at every plan level and never graduates; a custom domain is probationary until its scope has one qualified day. That classification decides which budget counters the transaction must lock, and the budget counters come before the ramp keys in the normative order — so it is read unlocked. That is sound only because ramp progress is monotonic: a stale answer can be stale in the strict direction and no other. This is the subtlest thing in the PR and the comment says so.
• The ramp is authorized last. A ramp hold therefore arrives with budget units already taken, and those are released before returning — keeping them would charge an account for a send its own domain was not allowed to make.
• SettleProvider moves the ramp: acceptance advances a qualified day, permanent rejection releases, retryable/ambiguous leaves the reservation standing.
• CancelAttempt releases both ledgers; DeferAttempt still releases only the budget, so a rate-deferred message cannot re-qualify a stage it already qualified.

Operational risk

Disabled mode is genuinely pass-through: no scope row, no counter, and no exempt write. That last one matters — writing exempt while the ramp is off would permanently grandfather every domain that sent during the disabled window, and the phase-3 activation would find nothing left to ramp. Production ships in exactly this state (ramp_enabled: false).

Test plan

• go test -p 1 -race -count=1 ./internal/sendingpolicy ./internal/sendramp ./internal/config ./cmd/e2a
• 264 tests in the package plus the existing ramp suite: 150/213/277 stage caps and their 75/107/139 qualification bars, every probation class, budget-allow/ramp-hold and its mirror, settlement idempotency, permanent-rejection release, defer-vs-cancel, subdomain scope sharing, Free-plan stage-two block with progress retained
• make fmt-check, git diff --check, synthetic-data scan
• Two internal/agent outreach-hook failures were baselined against clean origin/main and fail there too — pre-existing, not from this change

Fixture note worth keeping: the ramp ledger is keyed by registrable domain, so ramp-1.example.test and ramp-2.example.test are one scope. The first version of these tests read the hostname key, found empty rows, and would have passed for the wrong reason. Each fixture domain is now its own eTLD+1, and the one test that is about sharing builds two hostnames under a single registrable domain deliberately.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AjfGxvXW6fNKWGFHuo68yX