feat(ui): instant exclusion-preview re-evaluation from an in-memory tree

[pmaxhogan]

Editing an exclusion rule used to re-walk the entire source folder from disk. On a large source that is minutes of I/O per keystroke, to answer a question that cannot possibly depend on what is on disk - and while it ran, the tree blanked and every count dropped to zero before repopulating.

This separates the two jobs the preview had conflated: WALKING the folder, and CLASSIFYING it under the candidate rules.

Backend

A per-root, editor-scoped folder-tree cache (src-tauri/src/commands/preview_cache.rs) records each directory the first pass reads - rel_dir -> [{name, is_dir, size}], one entry per directory in read_dir order. Every later pass replays it from memory and touches the disk only for directories the cache does not have.

That single rule covers both cases the design called for. A directory an earlier pass PRUNED (excluded, no !-rule reaching in) is simply absent from the map, so a rule that now reaches into it is a cache miss, gets walked lazily, and is appended to both the stream and the cache. Presence per directory is the completeness signal, so no separate frontier set or global complete flag is needed - noted below as a deviation from the brief's shape.

The cache never stores a verdict. Classification runs fresh on every pass, threaded through the DirDecision cursor from #172 (root_decision() / descend() / is_included_at()), which now rides on the BFS queue entry.

Also in this pass:

• preview_exclusions_start returns its generation id IMMEDIATELY. Building the matcher reads the source's ignore-file cascade off disk - seconds on a repo-of-repos - and that moved into the spawned task. sources.rs splits resolve_preview_root_and_matcher into the fast, fallible resolve_preview_root (unchanged validation: globs, exactly-one-selector, dialog-token peek, readable-dir) and the slow build_preview_matcher. A matcher that fails to build now reports on a new exclusion_preview:error event carrying the same stable SPEC s24 code the rejection would have used.
• A superseded pass is DEMOTED to a silent cache builder rather than cancelled - its remaining walk is exactly the cache the new pass wants. At most one builder exists (the oldest survivor, furthest into the tree), so fast typing cannot stack more than two walks. Cancelling the preview stops both and frees the cache; a root change drops it.
• Memory is bounded at 4M entries. Over the ceiling the cache marks itself overflowed, frees everything, and stops caching - every preview then walks from disk exactly as before.

Frontend

start() no longer clears the tree or zeroes the totals. The incoming generation is built off to the side and swapped in whole on its FIRST batch, which with the cache lands within a frame or two. A recomputing ref dims the summary and tree behind an "Updating..." status in the meantime. A done also swaps (it is the generation's final word, even if it found nothing), but a CANCELLED one does not - that generation was abandoned and the tree on screen is still the best answer available.

Expansion and paging state now survive a rule edit too. Re-classifying the same folder used to collapse the whole tree on every keystroke, throwing away the user's place in it.

Measured

On a real 63k-entry tree: first pass 2.79s, then a rule edit reclassifies in 536ms against 868ms for a fresh re-walk of the now-OS-cached tree - and the cached path issues zero read_dir calls, so unlike the walk its cost does not scale with disk speed. On a 3.45M-entry Documents folder the budget overflowed as designed and the classification came out byte-identical to the full walk (23,264 excluded either way); that measurement is what set the 4M ceiling.

Deviations from the brief

1. The cache is a per-directory map rather than a BFS node list plus an explicit pruned-frontier set and completeness flag. Isomorphic, but it makes "walk this directory if we do not have it" the only rule, which is what unifies the cache-hit and lazy-frontier paths into one BFS.
2. The brief's superseded-walk design has the new generation "fed as the walk advances". Here both passes share the cache and each walks its own misses, so the new generation is never blocked on the builder and is fed by whatever the builder has finished. The cost is that they can duplicate one directory when they race on it; the alternative (following the builder, waiting on directories it has claimed) blocks the very path this PR exists to make instant.
3. Preserving expansion/paging state across a restart was not in the brief. It follows from "keep showing the previous result" - preserving the tree but collapsing it is still losing the user's place.

Gates

cargo fmt --check, cargo clippy -p driven-app -p driven-core --all-targets -D warnings, cargo test -p driven-app --lib (303 passed), cargo test -p driven-core --lib exclude (50 passed), npx vitest run (526 passed), npx prettier --check src, npx eslint . (0 errors) all pass. Merged origin/main (including #172) before opening.

Rust coverage added: cache-vs-fresh-walk equivalence over a matrix of 10 successive rule edits on one shared cache; a second pass proved to be pure-memory by DELETING the fixture between passes; lazy frontier walk matching a fresh walk exactly; overflow fallback staying correct; cancel freeing the cache; registry demotion, the two-walk bound, and both slots cancelling. #172's cursor-equivalence test now runs over the cached replay as well as the disk walk.

Vitest coverage added: the old tree staying visible until the new generation's first batch, totals never dipping through zero, done-swaps-empty vs cancelled-does-not, first-open publishing on batch 1, the error event (live, superseded, pre-id replay, cleared on restart), and component tests for the dimmed recomputing state and preserved expansion.

[github-actions]

Coverage

Area	main	this PR	delta
Rust (lib crates)	80.81%	80.92%	+0.11 (OK)
UI (vue/ts)	91.33%	91.40%	+0.07 (OK)

Gate: passed - no coverage regression (epsilon 0.1 pp).