perf: a new transcript no longer rebuilds the corpus (#99) - #112

Builds on #111 — the branch contains it, so review that one first; this commit is the part that makes the fast path actually reachable in practice.

Problem

After #111 the fast path handles several appends, but on a live machine it still almost never ran. The reason is that every new session starts a new transcript, and a file that had just appeared was classified as an unsafe source mutation:

const appendOnlyPlans = ... plans.every((plan) => plan.kind === 'append' && plan.prior && ...);

A new file has no prior, so the gate fails and replaceWithFullAnalysisPlans() rebuilds every contribution. On my machine, with agents running, this happens many times a day. Measured with the diagnostics after a restart, on a build that already had #111:

files(discovered=647 changed=6 reused=641)
incremental(bodies=647)          ← still everything
ms(read-parse=71 697)

Reproduced in isolation on a 64-file corpus, frozen clock:

Fix

A new file is as safe as a tail append: its own body is read in full and the established contributions are untouched. Concretely:

• let plans of the form "rebuild without prior and without a replaced id" through both gates alongside appends;
• add such a file's whole analysis as its delta (addAppendAnalysisDelta against an empty accumulator);
• recompute orderedFileIds / filePositionById only when files were actually added — that is metadata-only work and no body is re-read, and pure appends keep reusing the previous ordering, so the existing "does not revisit historical file contributions" guarantee is untouched;
• guard ownership: a new file carrying a UUID somebody already owns falls back to the full rebuild, since the full loader resolves that case by scan order. Covered by a test.

Measurement

Real transcripts, 15 files / 34 MB, two appended and one new file added:

Tests

Two cases added: a new session file alongside two appends stays at 3 body reads and matches the full loader, and a new file carrying an already-owned UUID falls back while still matching the full loader.

Full npm test on this branch: 1028 pass, 8 fail, 1 skipped — the same 8 environmental failures (Codex lease/manifest, EPERM: symlink, temp races) that a clean main produces here.

One thing worth knowing, unrelated to this change

File identity is (dev, inode), and NTFS reuses file record numbers. A file created during a test run can land on the identity of one the fixture already indexed, which reads as a move and legitimately forces a full rebuild. This makes the incremental suites flaky on Windows: across four full runs on this machine, one changed file in a reused corpus, default content analysis does not revisit historical file contributions and others failed on main as well, in a different combination each time. The new test skips itself when it observes changed.move > 0 rather than asserting a number the filesystem cannot deliver. Happy to open a separate issue with the details if that is useful.