The usage_count table exists: one stamped migration and nothing else

This adds the usage_count table as a single migration, src/core/migrations/20261016130000-usage-count.ts, and changes nothing else.

What it creates: usage_count(hour, pattern, method, status, role, surface, n INTEGER NOT NULL DEFAULT 0). The primary key is all six key columns, and the table is WITHOUT ROWID. status holds a class (2xx…5xx).
Stamp: the newest file on main is 20261016120000-*, so this one is stamped later. I copied the shape of 20261016120000-kept-is-a-person-s.ts.
Left out: no module, server wiring or page uses the table yet. I did not touch src/core/releases.json.
Tests: test/schema-migrations.test.ts, test/schema-additive.test.ts, test/sole-owner-suspend.test.ts and test/check-list.test.ts all pass (37 tests).
Type check not clean: bun x tsc --noEmit fails here with TS2688: Cannot find type definition file for 'bun'. That is the sandbox, not the migration. I did not check it against main, so the forge's check is the real verdict.
Try it: run bun test test/schema-migrations.test.ts. The table appears in a freshly migrated database.

Closes #2077

One stamped migration, as titled. It follows the folder pattern: a sortable id later than the newest file, a leading comment citing #2077, and a default-exported SQL string. The schema suite passes with it (20 pass). It adds no input, output, write path or dependency, so the security and both-doors checks have nothing to fail on. A WITHOUT ROWID table makes the composite key columns NOT NULL, so the hour/pattern/method/status/role/surface key cannot hold NULLs and the counter upsert will be unambiguous. Two things next: (1) in the writer pull, add a test that upserts the same key twice and reads n back as 2, so this key shape is proven. (2) Say in the README or AGENTS.md how long rows are kept, or add a pruning rule, so hourly rows do not grow without bound.

The usage_count table exists: one stamped migration and nothing else #2120

Keyboard shortcuts