P2: Serve the repository overview from stored summaries

Why

The repository overview is the page a visitor sees before choosing a file or an issue, and it read git on every request: the default branch tip, the last five commits, the tag list, the tree’s languages, the contributors’ shortlog, and the README blob. Everything except the README is a property of a ref, and a ref moves only when a push lands, so a page read was recomputing facts the push could have recorded.

The load harness measured 473 req/s at p50 8 ms for the overview with four workers, with four git processes per warm request.

Scope

• Record the default branch’s newest commits and language breakdown when the tip moves (one ls-tree -r -l), and its top authors when the hook sees a new tip.
• Store the tag rows when the tag refs are read (every push, plus release writes and rebuilds).
• Serve the overview from those rows when the recorded head is the current branch tip; fall back to git when it is not, so a missed hook shows the correct page rather than a stale one. A stored section that is empty on a repository with commits is re-read from git on its own.
• Ask SQL for the five open issues and changes the sidebar shows instead of sorting the whole open queue in memory.
• Cache the rendered README by repository, commit and ref under a byte budget.
• Keep Remove from leaving derived rows behind.

Acceptance

• A warm overview request starts no git process.
• A metadata or tag push does not run shortlog or walk the default branch’s tree.
• A stale or missing summary falls back to git and shows the same page as before.
• A rebuild restores the summaries and the release events.
• Overview throughput and p50 improve measurably in the load harness, with no regression on the home or activity routes.

Notes

The schema bump resets the index; the first read of each repository rebuilds its summary. vole admin index rebuild does that for every repository up front.