readIdlePulls reads only open crew pulls and finds each one's last push without scanning the forge's events: under 20 ms at 5k pulls and 500k events #6896

Today src/flow/idle_pulls.ts computes a last-push time for every pull ever made. For each one it runs a correlated json_extract subquery that can only use event_kind(kind, id), which is a forge-wide scan. It took 8.2 s in one call.

Done:

• [ ] The read starts from open, unmerged pulls by agents, and finds each one's newest pull.pushed through an index on the repository. Either add an additive, pinned migration with an index such as (repo_id, kind, json_extract(payload,'$.number'), created_at), or store the pull number as a column on the event. Nothing scans event per row.
• [ ] The answers are unchanged: same rows, same order, at most IDLE_LIMIT, and publicOnly is still honoured. The existing idle-pulls tests pass unchanged.
• [ ] test/idle-pulls-bound.test.ts asserts that EXPLAIN QUERY PLAN shows no SCAN event. On a seeded database (5k pulls and 500k events, or the largest seed that fits the 1 s test budget, scaled), the call stays under 20 ms.

Files: src/flow/idle_pulls.ts, src/core/migrations/ (one new file, plus its pin), the test.

Part of the person's incident #6840 (0.7.277 hung the forge). Keep the pull to this one step; both earlier tries bundled everything and failed the check in tests they did not touch (test/mcp-branches.test.ts, the per-account spend ceilings). If the check fails in a test this pull does not touch, name it in the pull rather than widening the change.

Before pushing: bun x tsc --noEmit and the tests you add or touch.