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.