/milestones and /milestones/:number answer under 50 ms on trevato/forge, each naming its Server-Timing phases #6152

The milestones page and the milestone page now share a plan cache keyed by what the plan reads, readPlan is faster, and /milestones/:number names session, repo, plan and render. bun test is not green on the whole suite in this sandbox. Three milestone-adjacent tests also fail with my change stashed (the TUI l log, tokens-by-pillar, the map deferred-issue page). The rest of the full-suite failures I saw looked environmental (sandbox network, chromium, ssh); I did not re-run those against main, so they are unconfirmed. tsc and design-lint are clean, and the milestones tests, limb-replan, flake and budget pass.

• Cache key: planStamp(db, repo) in src/core/milestones.ts replaces the forge-wide write stamp. It is built from this repository's issues, dependencies, pulls, runs (start, finish, cost) and limb places. A write to another repository leaves the cache warm; a new issue here refreshes it. Both are tested. Cost is about 3 ms per request against about 40 ms for a rebuild, and it returns undefined inside a transaction.
• Speed: readPlan measured 30–50 ms before and passes the 30 ms budget now, but the box was heavily loaded, so those are noisy wall-clock figures.

- limbTree copied a growing array for every edge; it now pushes. - repoGraph reads a big repository in one pass (getIssuesOfRepo, raisedInRepo) instead of chunked IN lookups, and reuses the pillars the caller already read. - A repository with 400 or fewer edges still takes the old path.

• Server-Timing: milestonePage takes the plan through the same cache as the list. That is the only thing the page's plan figure measures, and it makes plan cheap on a warm hit.
• Test: test/milestones-speed.test.ts builds the 2,300-issue, 10-pillar fixture once and asserts all three of your criteria. The speed check uses expectBudget, because the repo guards forbid raw millisecond bounds.

What I left out:

• The stamp does not see changes to who may write the repository, which affects which umbrellas count as pillars. The 60 s cache lifetime bounds that staleness.
• readPlan still reads every issue's body. A lean read would help real data more than the fixture, but Issue is shared and I did not want to change its shape.

To try it, open /<owner>/<repo>/milestones and /<owner>/<repo>/milestones/<n> twice and read Server-Timing; the second plan figure should be near zero.

Closes #6122

The milestones page and the milestone page now share a plan cache keyed by what the plan reads, readPlan is faster, and /milestones/:number names session, repo, plan and render. bun test is not green on the whole suite in this sandbox. Three milestone-adjacent tests also fail with my change stashed (the TUI l log, tokens-by-pillar, the map deferred-issue page). The rest of the full-suite failures I saw looked environmental (sandbox network, chromium, ssh); I did not re-run those against main, so they are unconfirmed. tsc and design-lint are clean, and the milestones tests, limb-replan, flake and budget pass.

• Cache key: planStamp(db, repo) in src/core/milestones.ts replaces the forge-wide write stamp. It is built from this repository's issues, dependencies, pulls, runs (start, finish, cost) and limb places. A write to another repository leaves the cache warm; a new issue here refreshes it. Both are tested. Cost is about 3 ms per request against about 40 ms for a rebuild, and it returns undefined inside a transaction.
• Speed: readPlan measured 30–50 ms before and passes the 30 ms budget now, but the box was heavily loaded, so those are noisy wall-clock figures.

- limbTree copied a growing array for every edge; it now pushes. - repoGraph reads a big repository in one pass (getIssuesOfRepo, raisedInRepo) instead of chunked IN lookups, and reuses the pillars the caller already read. - A repository with 400 or fewer edges still takes the old path.

• Server-Timing: milestonePage takes the plan through the same cache as the list. That is the only thing the page's plan figure measures, and it makes plan cheap on a warm hit.
• Test: test/milestones-speed.test.ts builds the 2,300-issue, 10-pillar fixture once and asserts all three of your criteria. The speed check uses expectBudget, because the repo guards forbid raw millisecond bounds.

What I left out:

• The stamp does not see changes to who may write the repository, which affects which umbrellas count as pillars. The 60 s cache lifetime bounds that staleness.
• readPlan still reads every issue's body. A lean read would help real data more than the fixture, but Issue is shared and I did not want to change its shape.

To try it, open /<owner>/<repo>/milestones and /<owner>/<repo>/milestones/<n> twice and read Server-Timing; the second plan figure should be near zero.