Stop re-rendering the file browser per streamed diff file

What does this MR do and why?

When a large merge request streams in, every streamed file replaced the whole map of loaded files in the file browser's state, which made the file browser re-render from scratch once per file. That work grows with the number of files and blocks the main thread while the diff is still loading. This MR collects the files that finished mounting during a frame and reports them to the file browser once per frame instead of once per file. No UI change.

Measurements

Local 1,000-file merge request (998 streamed files, about 85k elements), Overview tab then Changes tab, headless 1440x900, no extensions. Master and every variant were served by the same local stack in one session, with a warm-up run before recording, 4 runs each, medians. Blocked is total main-thread time in frames longer than 50 ms during streaming; longest is the longest single task. Time to the last file is not reported because the local server produces the stream in a burst whose timing varies by about half a second between runs.

Change	Chromium blocked	Chromium longest	Firefox blocked	Firefox longest
master	805 ms	324 ms	2,268 ms	970 ms
this MR	402 ms	114 ms	2,151 ms	737 ms

This is the whole Chromium win, and it is what makes the yields in !253645 pay off.

What was measured and left out

Freezing the loaded-files map was tried and dropped: it made no measurable difference (420 ms Chromium and 2,278 ms Firefox with it, versus 402 ms and 2,151 ms without). Splitting the file browser's tree structure from its per-row state was also tried and dropped to keep this MR focused: it was within noise in Chromium and worth about 90 ms in Firefox (2,058 ms versus 2,151 ms).

Reproduction steps

1. Open a large merge request in Rapid Diffs.
2. Go to the Overview tab, then the Changes tab, and record a Performance profile while the diff streams in.
3. Check that the file browser updates at most once per animation frame instead of once per file.
4. Confirm the loading spinners, active file highlight, and viewed checkboxes in the file browser still update correctly.

References

• !253645 is stacked on this MR and carries the streaming change.
• Sibling MRs from the same investigation, closed after measurement showed no effect on Rapid Diffs: !253737 (closed), !253738 (closed), !253739 (closed), !253740 (closed).
• Feedback thread: #596236

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.