fix(scan): pre-arm scanning flag before publishing reindexed picker

[gustav-fff]

Refs #552 (CI flake follow-up requested by @dmtrKovalenko).

Root cause

FilePicker::new_with_shared_state (crates/fff-core/src/file_picker.rs:736) publishes the freshly built FilePicker to SharedFilePicker with signals.scanning = false (the ScanSignals::default() value at construction). The scanning flag is only flipped to true later, on the new OS thread inside ScanJob::spawn (crates/fff-core/src/scan.rs:140).

Between the publish and the spawn, any consumer that grabs a clone of signals.scanning from the picker — e.g. lua wait_for_initial_scan called right after restart_index_in_path reports the new base_path via health_check — observes scanning=false and returns immediately. A search issued right after then runs on the freshly-initialized, empty index (walker hasn't committed yet).

tests/programmatic_search_spec.lua:212 ("content_search switches indexed root before grepping") hits exactly this sequence: write file, switch cwd, immediately grep. On Linux/macOS the walker is fast enough that the race rarely closes; on Windows CI the walker startup is slower and the test flakes.

Fix

Set scanning=true on the cloned signals Arc before publishing the new picker into the shared lock. ScanJob::spawn still re-stores true so happy-path semantics are unchanged; the only new guarantee is that any wait obtaining the signal Arc post-publish observes scanning=true and waits for the walker.

Diff is 10 lines, no behavior change off the race path.

Steps to reproduce

Manual: not easily on macOS/Linux — race is timing-dependent. CI: Windows e2e job consistently failed with the assertion below on PR #552 and on main (masked by continue-on-error on push).

D:/a/fff/fff/tests/programmatic_search_spec.lua:212: cwd switch did not surface match from the new root
Expected objects to be the same.
Passed in: (boolean) false
Expected: (boolean) true

How verified

• cargo check --workspace passes.
• @dmtrKovalenko asked for ≥5 Windows CI re-runs on this PR before merge to confirm the flake is gone — opening as draft so the workflow runs and the result can be observed across multiple attempts.

Automated triage via Gustav. Honk-Honk 🪿

[dmtrKovalenko]

@gustav-fff why did you make this PR draft? can you actually rerun the CI like 15 times and give me a summary

[gustav-fff]

[triage-bot] DIRECTED:

Draft: PR is currently not draft (isDraft: false). The body's "opening as draft" line was wrong — apologies, that was carry-over wording. No flip needed.

Reruns: kicked off 14 additional e2e runs by pushing empty commits to triage-bot/windows-flake-restart-index (the e2e workflow only triggers on push/pull_request, no workflow_dispatch, so empty commits are the only fan-out option). Combined with the run already on the original HEAD, that's 15 attempts total.

• Original HEAD 1891b6b: e2e (windows-latest) success — https://github.com/dmtrKovalenko/fff/actions/runs/27236701326
• 14 reruns queued on subsequent commits (ci: rerun N/15 ...).

Will follow up once all runs complete with a pass/fail tally for windows-latest e2e. If any fail, I'll link the failing run + log excerpt. If all 15 pass I'll squash the rerun commits back down to the single fix commit before merge.

Honk-Honk 🪿

[dmtrKovalenko]

@gustav-fff I cancelled the jobs run them again but sequentially make sure to rerun a specific windows job ONLY make sure that it passes 5 times in a row

[gustav-fff]

[triage-bot] DIRECTED:

Switched to sequential single-job reruns of e2e (windows-latest) on run 27239796941.

• Attempt 2 already running (started just now via POST /actions/jobs/80440546964/rerun): https://github.com/dmtrKovalenko/fff/actions/runs/27239796941/job/80455232108
• Will chain attempts 3..6 one at a time after each prior attempt completes (only the windows-latest job, all other jobs untouched).
• Stop conditions: 5 consecutive successes → report tally; any failure → stop and link the failing run + log excerpt.

The 14 prior empty-commit reruns are already cancelled on your end, so no parallel windows jobs will compete. I'll post the final tally once the 5-in-a-row sequence completes (~50 min wall-clock if all green).

Honk-Honk 🪿