Prioritize requested diff files without blocking on earlier slow loads

[kjanat]

Problem

The multibuffer diff loads files concurrently but presents results in order. A slow early file can prevent later, already-ready files from appearing, including a file explicitly selected by the user.

Source evidence

At 5ee612d, DiffMultibuffer::refresh collects entries in a BTreeMap and consumes loads with .buffered(MAX_CONCURRENT_BUFFER_LOADS) (16). Ordered consumption deliberately prevents excerpts shifting as files arrive, but means later completed loads wait for earlier ones.

DiffBufferList::load_buffer opens the buffer, awaits its diff, and obtains its conflict set before returning a displayable result. The viewer loads all changed files rather than scheduling only files near the viewport. Its pending target does not change the load order in refresh.

These are code-confirmed scheduling behaviors. We have not yet timed their contribution to the reported first-open delay.

Proposed change

Prioritize the explicitly requested file and the first visible content, and allow useful ready results to appear without waiting for unrelated slow files. Preserve stable ordering and scroll anchors; simply replacing buffered with unordered consumption would not satisfy the current no-jumping requirement. Consider reserved file positions or placeholders.

Regression scenario

Extend the existing incremental merge-base loading test: hold the first file's read, release a later explicitly requested file, and verify it becomes usable before releasing the first file.

Acceptance criteria

• An unrelated slow file does not block a ready requested file.
• File ordering, focus, selections, and scroll anchors remain stable as results arrive.
• Loading remains bounded and handles cancellation, failures, and repository switches.
• Measure time to requested-file display separately from total diff completion, in unified and split views.

Upstream research (2026-09-29)

• PR #62536 was merged on 2026-09-18 and is already an ancestor of this fork's investigated master. It introduced lazy loads, bounded ordered consumption, and immutable blob reads outside the serial Git queue. The author reported substantial branch-diff improvements. This issue is the remaining requested-file prioritization and ordered-result blocking tradeoff, not a claim that incremental loading is missing.
• Open issue #55392 reports an enormous generated-file diff blocking access to other files and proposes an explicit-load placeholder for oversized diffs. This is a useful related design option: scheduling alone cannot prevent a single large foreground registration step from blocking the UI.
• PR #64141 implements default-folded multibuffers but was closed without merging. The review cites lack of agreement on approach and review scope, not a demonstrated technical impossibility. Retain it as design/reference material. Folding after loading does not itself eliminate loading or diff construction costs.