perf(remote): rescan granularity is the project folder, not the file

[devsuitup]

refreshHost() reduces each changed path to its top folder via topFolderOf()
(remote-hosts.js:84-87) and builds toScan from folders
(remote-index.js:92,114-119). The worker then re-enumerates every .jsonl in
that folder (workers/scan-projects.js:20-25), and readSessionFile() reads
each one whole — fs.readFileSync then split('\n') then JSON.parse per line
(read-session-file.js:167-169,193), with no offset and no incremental path.

Consequence: a 22 MB transcript that gains one line causes that whole file, plus
every other transcript in the same project folder, to be re-read and re-parsed.
For a host with live sessions writing continuously, this is paid every cycle.

It runs in a worker, so the UI does not freeze — the cost is CPU and memory, not
responsiveness.

Scope: make the scan unit the file, or make the parse incremental from the last
known offset. Either changes the cost from proportional-to-folder to
proportional-to-change.

[devsuitup]

The two approaches this issue offers are not alternatives — they compose, and
either one alone leaves half the cost on the table.

Granularity decides which files to re-read. The inventory already carries
size and mtime per file; that is how the mirror decides what to fetch.
topFolderOf() throws that away by widening a changed file to its whole project
folder. Keeping it removes the "neighbours" cost.

The offset decides how much of each file. A .jsonl transcript is
append-only in the normal case, so remembering where the last read stopped turns
the cost from proportional-to-file into proportional-to-change.

Two guards, without which the offset is wrong rather than slow

Prove it was an append, not a rewrite. Size and mtime are not enough: a
rewrite that ends up larger passes both, and the parse then resumes from the
middle of a file as if it were a continuation. Store a fingerprint of the prefix
already consumed — a hash of the first few KB — and compare before resuming;
fall back to a full re-read when it differs. This is not hypothetical: the
missing-project remap rewrites .jsonl files atomically, so the case really
happens.

Never store an offset mid-line. A transcript being written often ends in an
incomplete line. The offset kept must be that of the last complete newline,
with the remainder re-read on the next cycle. Otherwise a line is occasionally
lost or parsed truncated — intermittently, which is the worst shape for this
kind of bug.

Scope note

readSessionFile() serves local indexing too, which is the larger volume. That
is where the value of this issue is, and equally where its risk is: the same code
path backs local sessions that work today. Any change here needs the local path
pinned first.