A usage counter batches request counts in memory and writes them to usage_count in one transaction #1917

Part 2 of #1808. A module and a table, not wired into the server yet.

Done looks like:

• [ ] src/core/usage_count.ts (not usage.ts, which is the spend ledger) exports a counter with count({pattern, method, status, role, surface}), flush() and readUsage(db, sinceHour). Role is anon|user|admin|agent, surface is api|mcp|web, status is kept as its class (2xx…5xx); anything else is refused at the call.
• [ ] count is one in-memory increment and runs no query. flush writes every pending key in one transaction as an upsert on (hour, pattern, method, status class, role, surface). It flushes on its own after about a second or 500 keys, and on stop().
• [ ] A migration adds usage_count with that key as its primary key. It is a stamped file, src/core/migrations/<UTC yyyymmddHHMMSS>-<name>.ts like 20261015230000-a-domain-drill.ts, never a number (both earlier tries broke on numbering); do not hand-edit src/core/releases.json. The schema-migrations and schema-additive tests pass.
• [ ] test/usage-count.test.ts: three counts of one key are one row of 3 after a flush; no row exists before the flush; two hours make two rows. It is named in GATE in scripts/gate.ts in the same commit.

Files: src/core/usage_count.ts, src/core/migrations/, src/core/schema.ts if migrations are listed there, the test, scripts/gate.ts. Run bun x tsc --noEmit, the new test, the schema tests and test/check-list.test.ts before pushing.

Parked by the crew: the check failed ("suspending an organization's last active owner > (unnamed)") and the decider saw no point in another try (pull #1961 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check stayed red through 2 automatic tries (pull #2003 closed).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check failed ("suspending an organization's last active owner > (unnamed)") and the decider saw no point in another try (pull #1961 closed)
2. the check stayed red through 2 automatic tries (pull #2003 closed)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Split into #2077 (the usage_count migration alone) and #2078 (the counter module and its test, not wired in; waits for #2077). Both tries went red on test/sole-owner-suspend.test.ts, which neither touched, and #2003 also grew into server wiring, a page, MCP and a terminal screen. Each part is now small enough that a red check points at one file, and each says to name a failure that main shares rather than chase it. #1918 now waits for #2078.