Every git process the forge spawns is timed per subcommand, and the performance watcher files a finding when its p95 passes a budget #8158

Intent: when git processes queue on the forge, the forge says so itself, instead of each route looking slow for no named reason.

Seen 2026-11-02: two git rev-parse calls took 7 s (head phase of a pull read), and the merge readings of 47 pulls took 26–71 s. That points to git processes waiting on a loaded machine, but nothing records it. src/perf/record.ts keeps route samples and src/perf/duty.ts files findings from them.

Done looks like:

• [ ] The git spawn helpers in src/git/local.ts record each process's wall time under git <subcommand> (subcommand only, never arguments, paths or refs) in a record sized like the route record (15-minute window, bounded).
• [ ] src/perf/budgets.ts gives git subcommands a p95 budget (for example 250 ms). The watcher files one issue, as it does for a route, naming the subcommand, its count, p50 and p95.
• [ ] Tests: a recorded slow rev-parse past the budget makes the watcher file exactly one finding; arguments never appear in the record; the record stays bounded.

Files: src/git/local.ts, src/perf/record.ts or a new src/perf/git.ts, src/perf/budgets.ts, src/perf/watch.ts, tests. Risk: timing must not add a measurable cost per spawn (one performance.now() pair).