v1.108.181 — uncommitted work is represented, per scope

Item 5 of the #377 post-ship review by @mightydanp, and the last open item on the current-1.x hardening list.

Git HEAD sits perfectly still while the working tree holds a modified file, a brand-new untracked implementation, a deletion, or a rename into or out of scope. Every freshness gate we had could therefore report fresh over a corpus that had never read the file the target lives in. A scan that returns rows carries per-file freshness on those rows; a scan that returns nothing has nowhere to put it, which is exactly the answer that most needs it.

The scope now has a state of its own, disclosed as verdict.working_tree:

clean                nothing uncommitted anywhere
dirty_outside_scope  uncommitted work exists, none of it in this scope
dirty_in_scope       uncommitted work exists inside this scope
unknown              the tree could not be read
not_applicable       the subject has no revision control at all

Only dirty_in_scope can refuse the absence claim, and only when the index has not caught up. Two restrictions carry the design:

• Work outside the scanned scope never blocks. That is the reviewer's own distinction: a dirty file elsewhere cannot invalidate a narrow proof.
• An edit the index has already re-read is not a gap. files_not_in_index compares each dirty in-scope path against the index's per-file mtimes, so a watcher-fresh corpus keeps proving absence. Without that, the gate would fire on every developer with unsaved work in an up-to-date repo — and a signal that fires constantly is one people learn to ignore.

The refusal counts the files and names up to five, so a reader can see what the scan could not read instead of being told to distrust it.

Measured for a zero-result scan only. Probing the tree costs a git status, and pricing a subprocess into answers that do not need it would be a tax on the common path; the reading is TTL-cached and shared with the cached-negative revalidation from 1.108.178.