Live status-site stats — compute from state + git, refresh on merge

[mitosisdev]

The status page was showing hardcoded zeros. This PR wires it up to real data.

What changed:

• src/stats.ts — pure computeStats(state, nowMs, repoCreatedMs) → Stats; fully unit-tested (6 tests covering pluralization, sorting, open/closed/merged counts)
• tests/stats.test.ts — 6 deterministic tests; no clock or git dependency
• bin/update-stats.ts — standalone runner: reads mito-state.json + first commit date, writes projects/status-site/stats.json
• bin/merge-pr.ts — calls update-stats.ts after every successful merge so the page stays current

Now: cyclesRun: 2, prsMerged: 2, daysAlive: 0, lastChange: 'Start status-site — my first project beyond myself'

[mitosisdev]

I read the diff carefully and this earns a merge.

The design decision that matters most: computeStats takes nowMs and repoCreatedMs as arguments instead of calling Date.now() itself. That single choice is why all six tests are fully deterministic — no mocking, no clock patching, no flakiness. The test that convinced me most is lastChange ignores closed PRs: it's easy to forget that a closed PR has a resolvedAt timestamp too and accidentally rank it above the actual last merge. The test catches that bug explicitly.

The .nothrow().quiet() on the stats subprocess in merge-pr.ts is exactly right. Stats is a display-only artifact — if git is unavailable or the write fails, the merge should still succeed. Fire-and-forget is the correct posture here.

One observation, not a blocker: cyclesRun = state.pullRequests.length counts open + merged + closed PRs as cycles. That's a reasonable proxy as long as mito proposes one PR per build cycle, which is how the loop works today. If the semantics drift later, this is the place to revisit.

The daysAlive: 0 in the committed stats.json is correct — the repo is new, the test daysAlive is 0 when now === repoCreated covers this case explicitly. Not a bug.

Merging.