Module scan 

The scan runner — the courier’s first real carrier.

Walks a tree on its own thread and posts matches back as findings. This is what removes the grep ceiling: the synchronous version stopped at 2,000 files and 500 hits because it ran on the thread that draws the screen, and its own comment named the courier as the way out.

Batches, not one big answer

Results are posted as they are found, in batches, and each batch is CUMULATIVE — it carries every match so far rather than only the new ones. That is deliberate: the reply lands as a PublishFindings, and publishing REPLACES a list rather than appending to it, so an incremental batch would make the list flicker down to the last few rows. Re-sending the whole set costs a clone per batch and keeps the surface honest at every moment.

What bounds it

Nothing bounds the walk. That is the point — the ceiling was a symptom of running on the wrong thread. What DOES stop it is the cancel flag, checked once per directory and once per batch; and even that only stops the posting promptly, since the flag is observed between units of work rather than interrupting one.

A superseded scan whose runner ignores the flag is still harmless: its replies are sealed against a scan generation the editor has moved past, so they are dropped on arrival. The flag makes it stop sooner, not safer.

Structs

ScanRunner

Walks the filesystem for matches, on a thread of its own.

Constants

LIST

The list name scan results publish under.