fix(pi-fff): avoid blocking session start during finder warmup

[cokekitten]

Summary

Fixes #477.

pi-fff currently awaits ensureFinder() during session_start, and ensureFinder() calls FileFinder.create() followed by waitForScan(15000). Since Pi recreates the session runtime for /new and /resume, this can make session switching appear stuck while the finder scan warms up.

This change:

• schedules finder warmup after session_start returns, so Pi session replacement is not blocked
• keeps tool behavior intact: the first fff tool/autocomplete use still awaits the shared in-flight finderPromise if warmup is not done yet
• adds a lifecycle guard so stale warmups from a previous session do not notify or affect a newer session
• returns the local createdFinder from ensureFinder() after waitForScan() to avoid returning a destroyed/replaced global finder if shutdown happens during warmup

Validation

cd packages/pi-fff
npx tsc --noEmit

[dmtrKovalenko]

to actually get rid of the wait we proably should redesign the waitForScan internally, it is anyway blocking now while it should do the pool for is_scanning

[cokekitten]

Agreed. This PR only removes the session_start blocking path; waitForScan itself can still block the first tool use. I kept the scope small here, but happy to follow up with a separate PR redesigning waitForScan to poll is_scanning internally if you prefer.

[dmtrKovalenko]

@gustav-fff please update the PR to include the refactoring and rebase on top of the main (use merge not rebase to be able to push to fork)

[gustav-fff]

[triage-bot] DIRECTED: cannot push merge to fork — gustav-fff OAuth token lacks workflow scope, and merging main brings in .github/workflows/* changes. Github rejects: refusing to allow an OAuth App to create or update workflow .github/workflows/external-tests.yml without workflow scope. Options: (1) you push the merge yourself from cokekitten/fix-pi-fff-nonblocking-session-start, or (2) re-target this PR to a same-repo branch so I can push. Also — need scope confirmation on the refactor: packages/fff-node/src/finder.ts:438 already polls isScanning() async in JS; the blocking one is C FFI fff_wait_for_scan (crates/fff-c/src/lib.rs:836) used by fff-bun. Do you want the refactor in fff-node (drop the blocking C wait entirely, keep JS polling), in fff-bun (same async polling as fff-node), or in Rust SharedFilePicker::wait_for_scan (crates/fff-core/src/shared.rs:119)?

Honk-Honk 🪿