Free-tier inspection cap counts what exists, not what was created

[important-new]

The free-tier inspection cap read a monotonic counter, so deleting an
inspection never returned the allowance. A tenant who cleaned up a duplicate
stayed capped, and a counter that drifted above the real row count refused
someone who was genuinely under the cap. The only remedy was editing the
counter by hand, which is not a remedy.

The gate now counts the inspection rows a tenant has. usage_counters.value
for this metric degrades from source-of-truth to a self-healing display cache.
No migration, no schema change.

The statement

Still one statement, so meta.changes === 0 remains the authoritative "at cap"
answer with no read-then-write window inside the guard. Two things a probe
forced (tests/unit/quota/inspection-cap-counts-rows.spec.ts pins both):

• INSERT ... SELECT ... WHERE, not VALUES. A conflict-free INSERT never
  reaches DO UPDATE, so that branch's WHERE cannot refuse anyone — a tenant
  with rows but no counter row walked straight past the cap. One predicate now
  governs both branches. (excluded.tenant_id is in scope inside
  DO UPDATE ... WHERE and resolves per-tenant; verified on real D1, so no
  bound-parameter fallback is needed.)

• consumeInspection(tenantId, count). Because the gate counts rows the
  caller inserts only afterwards, N looped calls all read the same count and
  all pass. A multi-sub inspection request consumed in a loop, which took a
  tenant from 3 inspections to 6 deterministically. The batch is now consumed
  as one unit and is admitted whole or not at all.

The trade this makes, deliberately

The caller inserts its row after consumeInspection returns, so two creates
that overlap before either row lands both pass. No formulation recovers the old
serialization: an in-flight claim and a counter left high by a delete are the
same stored state, so any predicate that lets the counter fall to match rows can
be raced, and any predicate that blocks a high counter re-breaks the case this
fixes.

So the cap becomes a steady-state invariant rather than a serialized claim.
The overshoot is bounded by in-flight concurrency and self-corrects, because the
next create counts what actually exists and refuses. That is the better trade:
the previous design bought serialization with a counter that could only climb,
which is what cost users their allowance permanently.

tests/workers/quota-cap-concurrency.spec.ts pins both halves under real
workerd — at the cap, six genuinely concurrent consumes all fail; below it, the
bound reproduces and then self-corrects.

Not touched

sms and email keep tallying. They are consumed events with no rows to count,
so converting them to a row count would silently uncap them. Asserted.

Standalone deploys are unaffected — the guard is only constructed when the
deployment profile enables usage quotas.

Also

GET /api/usage/summary reports the live row count for a tenant whose
inspections are capped: the number shown against a cap has to be the number the
cap is enforced against, or someone who deletes three inspections is told they
are at the limit while creating works. Uncapped tenants keep the cumulative
lifetime counter, which is measured against nothing and should not quietly
change meaning.

Verification

lint · test:unit · test:web · test:workers · db:check — all green.

🤖 Generated with Claude Code

[important-new]

Superseded by #299, which already contains this work.

Verified rather than assumed: 7 of the 9 files this PR touches — including all six test files — are byte-identical to main. The two that differ do so in the other direction (main has more: the aiCaps loader and the request-service extraction), and main already carries consumeInspection(tenantId, count = 1) plus the counter-is-a-cache note that were the substance here.

Note for anyone auditing this later: git cherry reports all five commits as unmerged, and that is an artefact of the squash — patch-ids cannot survive it. The file comparison is the reliable check.