Stream large -z git output instead of buffering it against the cap

[tyrielv]

Summary

Follow-up to #2048. That PR bounded the previously-unbounded git stdout/stderr capture and, for the two commands whose full result is correctness-critical, added a large stdout cap plus fail-safe valves if the cap was ever exceeded. This PR removes that truncation exposure entirely by streaming those commands' output instead of buffering it.

• DiffCachedNameStatus (diff --cached --name-status -z) feeds every staged path into ModifiedPaths.
• StatusPorcelain (status --porcelain -z) drives the sparse dirty check.

Both use -z (NUL-delimited), so line-based streaming can't chunk them — git delivers the whole blob as a single "line."

Change

Add a NUL-delimited streaming mode to InvokeGitImpl: a new parseStdOutToken callback reads stdout synchronously and splits on \0, invoking the callback once per record as it arrives. stderr stays async (BeginErrorReadLine), so the synchronous stdout read is deadlock-safe ("one sync, one async"). Only one record is held in memory, so an arbitrarily large result streams with no buffering, truncation, or OOM. It keeps git's robust -z format (no path-unquoting) and is guarded to timeoutMs == -1 and mutual exclusion with parseStdOutLine.

DiffCachedNameStatus and StatusPorcelain now stream tokens; their callers drive small status/path state machines. This removes the interim fail-safe valves from #2048 (there's no longer a partial result to guard against) and the dead -z string parsers (GetPathsNotCoveredBySparseFolders, GetNextGitPath). Result.OutputTruncated/ErrorsTruncated remain for the still-buffered commands (stderr is still bounded), but the two converted commands can no longer trip OutputTruncated.

Tests

• ReadStdOutTokens: NUL splitting, empty input, embedded empty records, a trailing record without a NUL, and a record spanning the 8KB read buffer.
• DiffCachedNameStatus/StatusPorcelain stream records through the mock.
• Replaces the removed GetNextGitPath test; PathCoveredBySparseFolders tests unchanged.

Full unit suite: 889 passed, 0 failed (11 pre-existing native-hook skips).

[Nathan Baird (ShiningMassXAcc)]

The streaming rewrite and the deadlock reasoning look sound to me — one sync/one async read, stderr drained via BeginErrorReadLine, watchdog kill guarded under processLock/readCompleted. I have one robustness concern I'd like addressed before final approval.

After ReadStdOutTokens returns (stdout at EOF), the streaming branch calls the parameterless this.executingProcess.WaitForExit() (infinite). By that point readCompleted = true is already set in the finally and the watchdog is disposed — so this final wait has no safety net. On the timeout-kill path (killedByTimeout), you TryKillProcessTree(...) and then fall into this same unbounded WaitForExit(). If the tree-kill only partially succeeds (a surviving grandchild still holding the pipe, or a wedged git), the calling thread pins forever — which is exactly the maintenance/prefetch hang this PR family (cf. #2046) is trying to eliminate. Narrow window, but it reintroduces the failure mode.

Suggestions:

1. Bound the post-EOF wait — WaitForExit(grace) with a small finite grace; on expiry, TryKillProcessTree again and return a failure/timeout Result instead of trusting a partial exit code. Keeps "never hang indefinitely" true on both the stream and buffer paths.
2. Still call the parameterless WaitForExit() once on the success path (it's instant once the process is gone) so the async stderr readers are guaranteed flushed before you read Errors — don't lose that property by switching to the int overload alone.
3. Derive the grace from timeoutMs when one was set (reuse it, or a generous fixed ceiling of 30–60s when infinite) so callers that opted into a bound get a bound end-to-end.
4. Log a distinct event if the post-EOF wait expires (same spirit as Bound runtime credential fetch so prefetch can't hang on auth #2046's CredentialFetchTimedOut) so a field occurrence is measurable rather than an invisible hang.

Net: the logic is good; the only real gap is that the final wait is the one place with neither a timeout nor the watchdog covering it. A bounded wait + re-kill closes it.