perf: keep multi-file appends on the incremental path (#99) - #111

Second half of the CPU path in #99, on top of #109 (independent — this one stands alone, but the profile in #109 is what pointed here).

Problem

With #109 merged, the extension host on this machine still held a core. The profile moved rather than cleared: 74% addToBucket, 25% analyzeLine. Not a parsing cost — a volume one. The diagnostics say it plainly:

files(discovered=644 changed=3 reused=641)
io(bytes=1 398 890 034  lines=449 046)
incremental(bodies=644)
ms(manifest=0.87  read-parse=55 824  total=56 729)

Three files changed; 644 bodies re-read, 1.4 GB, 56–86 s per refresh. With startup, focus, watch and poll all triggering, refreshes never finish before the next one is due.

The cause is the content-analysis gate:

const soleSourcePlan = sourcePlans.length === 1 && plans.length === 1 ? sourcePlans[0] : undefined;
const safeTailAppend = Boolean(soleSourcePlan?.kind === 'append' && ...);
const unsafeSourceMutation = deletions.length > 0 || moves.length > 0 ||
  (sourcePlans.length > 0 && !safeTailAppend);

Exactly one changed file. A machine running several agents appends to several transcripts between two refreshes, so the gate never holds and replaceWithFullAnalysisPlans() turns all 644 files into rebuild plans. One user with one session gets the fast path; anyone running concurrent sessions gets a full rebuild forever.

Fix

The application side already loops over parsedPlans, so only the gate limited this. Allowing N pure tail appends needs two ordering guarantees the single-file case never exercised:

1. Parse appends in full-scan order. The first file to carry a UUID owns it, so parse order must match the full loader's. The comparator returned 0 for two appends (if (left.kind === 'append') return 0), leaving discovery order to decide — which is exactly what the existing test concurrent appends resolve new content UUID owners in full-scan file order forbids. That test failed with the gate opened and passes once the comparator orders appends by timestamp.
2. Attribute each new UUID to the file that carries it, earliest first, instead of parsedPlans[0].fileId — correct while only one plan could ever reach that code, wrong as soon as two can.

The per-file UUID ownership check that forces a rebuild now runs for every appended file instead of only a lone one.

Measurement

Real transcripts, 15 files / 34 MB, three of them appended (frozen clock so the analysis cutoff does not move between passes):

Tests

New case concurrent appends to several files stay incremental instead of forcing a full rebuild: 64 files, three appended, asserts bodyReads === 3, exact appended byte count, and deepEqual against ClaudeDataLoader.loadUsageRecords. It fails on main with actual: 64, expected: 3.

claudeIncrementalIndex suite: 39/40, the one failure (content analysis is materialized from per-file contributions without a second body scan) fails identically on a clean main here.

Full npm test: 1025 pass on this branch and 1025 on main. The 8–9 failures are Windows filesystem cases (EPERM: symlink, temp rename/rmdir races) in the Codex lease/manifest suites, and their exact set shifts between runs on the same commit — two runs of this branch failed different members of that group.