fix: treat .pkl and .pickle as text files

[gustav-fff]

Closes #550

Root cause

is_known_binary_extension in crates/fff-core/src/file_picker.rs:1981 listed pkl and pickle under ML/Data Science binaries. .pkl is now also the Pkl configuration language — plain text. Files were classified binary, so preview rendered as binary.

Fix

Removed pkl and pickle from the binary extension match list (file_picker.rs:2022).

Steps to reproduce

mkdir /tmp/pkl-repro && cd /tmp/pkl-repro
cat > config.pkl <<'PKL'
name = "example"
port = 8080
PKL
nvim config.pkl
# :FFFFind, select config.pkl — preview shows "binary file" placeholder on pre-fix main.

Expected: text preview with syntax. Actual (pre-fix): binary placeholder.

How verified

cargo check --workspace passes. Diff is one line.

Automated triage via Gustav. Honk-Honk 🪿

[dmtrKovalenko]

@gustav-fff why this PR is failing windows CI second time in a row?

[gustav-fff]

[triage-bot] DIRECTED: not caused by this PR.

Failing test: programmatic search APIs cwd switching content_search switches indexed root before grepping at tests/programmatic_search_spec.lua:212. Windows-only.

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

Same failure on main (latest push a0c66d9, run 26778630912 job 78936826418 — Windows e2e fails identically). It only goes green there because the workflow has continue-on-error: ${{ github.ref == 'refs/heads/main' && github.event_name == 'push' }} (.github/workflows/external-tests.yml:24), which masks the failure on main but not on PRs.

Symptom: after content_search(marker, { cwd = sandbox_root }) swaps the indexed root, the freshly written grep_target.lua is not surfaced. Likely race between FS-watcher-driven reindex and grep on Windows (slower NTFS notify), not the binary-extension change in this PR. PR diff is one line in is_known_binary_extension, no relation to grep / cwd switching.

Suggest tracking as a separate Windows-flake issue. Want me to open one?

Honk-Honk 🪿

[dmtrKovalenko]

@gustav-fff try to open a separate PR to fix this issue, rerun the CI at least 5 times to make sure that it is gone until you figure out the exact reason what is going on

[gustav-fff]

[triage-bot] DIRECTED: opened #587 with the fix.

Root cause: new_with_shared_state (crates/fff-core/src/file_picker.rs:736) publishes the new picker into SharedFilePicker with signals.scanning=false, then ScanJob::spawn flips it to true on a separate thread. Between publish and spawn, lua wait_for_initial_scan (called via ensure_indexed after restart_index_in_path swaps the base_path) clones the signal Arc, sees scanning=false, returns immediately, and the test greps the empty index. Windows walker startup is slow enough to make that window large.

Fix is 10 lines: set scanning=true on the cloned signals Arc before publishing the picker. ScanJob::spawn still re-stores true so happy-path semantics are unchanged.

Will queue ≥5 Windows CI runs on #587 once the first one completes and report results back here before requesting merge.

Honk-Honk 🪿