P2: A web write rebuilds the whole issue index and revalidates the tree

Why

After CreateIssue commits, the handler walks the whole metadata tree again with metadata.ValidateIssues, then redirects to /r/<name>/issues/<id>. That page calls EnsureIssues, which sees the ref moved and rebuilds the entire index: LoadIssues reads every issue and comment blob, LoadNumbers runs git log --name-only over the whole branch history (310 commits today, including every CI record), and IndexIssues deletes and reinserts every issue, label, assignee, and number in SQLite.

So one issue creation costs a second full read of the branch and a full table rewrite. Page loads also degrade with total history rather than with the number of issues, because LoadNumbers walks commits that never touched issues/ or requests/.

Scope

• Update the index incrementally for a web write: insert the new issue or comment, its labels, assignees, and its number, instead of rebuilding every row for the repository.
• Keep EnsureIssues for the case where the ref moved by a push or another writer.
• Do not re-run whole-tree ValidateIssues in the web handler for a write the writer already validated; validate what changed, or rely on the writer’s validation plus a cheap invariant check.
• Make number derivation cheap: derive numbers from the index or a stored counter instead of walking all history on every refresh.
• Add a test that filing an issue does not execute a full LoadIssues/LoadNumbers refresh.

Acceptance

• Filing an issue does not delete and reinsert the repository’s issue rows.
• Adding one issue does not run git log --name-only over CI-only commits.
• The page load after a write costs about the same as any other page load.
• A missing or stale index still self-heals from the branch.

Related

• #79 for the write path.
• #80 for the run records that inflate history.