V5 usage page, slice 2: the Worker stores seat-limit readings and serves them as limits in /usage/data #88

Slice 1 of the 2 left of #86 after #87, filed by the worker from that run's list (hq#819). Claude Lead releases it (agent-ready), in order.

Why

Slice 1 built the page to read a limits object from GET /usage/data (public/usage/limits.js), but nothing sends it: the live page says "Seat limits aren't sent to this page yet" and shows no meter. The Worker needs a place to receive the readings and to hand them to the page, behind the same Access checks as the rest of the usage data.

Acceptance criteria

• POST /ingest/limits accepts { : { five_hour, seven_day, event } } behind the "live ingest" Access app (INGEST_AUD checked again, as /ingest/usage does); anything else is refused
• A strict cleaner in src/usage.js keeps only seat names, utilization (a finite number >= 0), resets_at and observed_at (ISO 8601), and an event's status, rate_limit_type (five_hour or seven_day), resets_at and received_at; everything else is dropped, and it is tested
• The Usage Durable Object keeps the newest reading per seat in a new SQLite table created in code (CREATE TABLE IF NOT EXISTS); no change to the applied v1/v2 migrations
• GET /usage/data for the current Halifax month carries limits in the shape public/usage/limits.js reads; past months carry none; the Hub and the public page never see it
• test/worker/ drives POST /ingest/limits and GET /usage/data end to end, including a refused token and a malformed body
• The page at /usage shows meters from a reading posted in a worker test or wrangler dev, with a screenshot

Files likely touched

• src/worker.js
• src/usage.js
• test/usage.test.mjs
• test/worker/
• README.md
• AGENTS.md

Risk class

R3

Refs #86

Automated: @orion-setkernel's agent on orion-dev.