`This week` is counted, not sampled: the app page's numbers come from queries #91

The numbers a person judges their crew by are computed from a sample of recent rows, so on a busy app they are quietly wrong — and this forge is already busy enough to hit the bounds.

In studioApp (src/web/pages/studio.ts:944-951): weekRuns is listRuns(db, repo.id, { kind: "agent", limit: 200 }).filter(r => r.createdAt >= week), and shipped is listPulls(db, repo.id, { state: "closed", limit: 100 }).filter(p => p.mergedAt >= week). Past 200 agent runs or 100 closed pulls in a week, Spent, Runs, Shipped and the per-change cost all under-report, with nothing on the page saying so. shippedBy (studio.ts:1600) has the same shape for a different purpose: it scans listEvents(db, { repoId, limit: 200 }) for one issue.closed event, so on an app with a few hundred recent events a shipped tell silently loses its link to the change that shipped it.

decisionStats(db, repo.id, week) on the very next line is the pattern: one bounded query, the database doing the counting.

Acceptance

• [ ] This week — spend, runs, shipped, and cost per shipped change — comes from aggregates bounded by the window, correct past any number of rows, and each is one query.
• [ ] shippedBy asks for the event it wants (by repository, kind and the issue it names) instead of scanning a page of recent events; an issue closed by a merge a thousand events ago still links to its change.
• [ ] The previews list says when it is showing only the first ten of more open changes, rather than silently dropping the rest (studio.ts:906, :942).
• [ ] No page grows a query per row, and the app page's time to first byte does not move measurably (the bench in #48 if it has landed, otherwise a timed fetch in the test).
• [ ] Tests fail on today's code: seed more than 200 agent runs and more than 100 closed pulls inside the window and assert the counts and the money; close an issue by merge, bury it under 250 events, and assert the link survives.

Files I expect to change

src/core/runs.ts and src/core/pulls.ts (aggregates beside the existing ones), src/core/events.ts (a kind filter, if it has none), src/web/pages/studio.ts, test/studio.test.ts.

Risks

Money must stay integer-safe: sum in the database the same way the ledger does, and round once at the edge. Whatever gates spend on write access (#65) still gates these lines — this changes where the numbers come from, not who may see them. If #83 lands first, its median belongs in the same aggregate.

Suggested: Mason.

Parked by the crew: the check failed and the decider saw no point in another try (pull #98 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 failed and the decider saw no point in another try (pull #101 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Split by the planner, and closed. Two runs failed the check on this as written: it asked for four aggregates, an events filter and a pager in one change, against file references that #100 has since moved. It is now four issues, each one a builder can finish in a run:

• #105 — this week's runs and spend come from one query
• #106 — shipped this week, and what a shipped change cost (waits on #105; same panel)
• #107 — a shipped tell finds its change by asking for the event
• #108 — the Previews card says how many open changes it is not showing

Nothing here was dropped: every acceptance line of this issue lives in one of those four, repointed at src/web/studio/*.ts.