fix(pi-fff): isomorphic bun/node SDK lazy-load

[gustav-fff]

Closes #668

Root cause

packages/pi-fff/src/index.ts:21 had a top-level import { FileFinder } from "@ff-labs/fff-node". @ff-labs/fff-node pulls ffi-rs and the optional per-platform native binary packages (@ff-labs/fff-bin-*) into its module graph. oh-my-pi statically resolves every extension import to validate the extension; the optional native package for a foreign platform is not on disk, so validation fails even though the runtime install would be fine.

Reporter also flagged that pi runs under both bun and node — but pi-fff only ever loaded the node SDK, so bun hosts paid the ffi-rs cost instead of using @ff-labs/fff-bun which shares the same FileFinderApi.

Fix

• Drop the static FileFinder value import; keep @ff-labs/fff-node for type-only imports (erased at compile time, invisible to the static validator).
• New detectRuntime() checks globalThis.Bun and process.versions.bun.
• New loadSdk() does a variable-name await import(pkg) for the runtime-appropriate SDK, with a fallback to the other one. Variable-name import defeats static resolvers.
• Result cached in sdkPromise so a single load survives concurrent tool calls.
• ensureFinder() now await loadSdk() before FileFinder.create(...); the existing in-flight-promise guard from pi-fff: parallel ffgrep calls can hang indefinitely due to unsynchronized ensureFinder singleton #403 still serializes creation.
• package.json: add @ff-labs/fff-bun as an optional peer dependency so bun-hosted pi pulls it in without forcing node-hosted pi to install it.

Both SDKs implement the identical FileFinderApi (packages/shared/fff-api.ts:528), so the call sites don't change.

Steps to reproduce

git checkout main
cd packages/pi-fff
bun install
# The static import chain is visible to any resolver that walks it:
node -e "console.log(require.resolve('@ff-labs/fff-node'))"
# oh-my-pi's static validator follows @ff-labs/fff-node -> ffi-rs -> optional native binary,
# which is missing for platforms other than the host and aborts validation.

Expected: extension loads under oh-my-pi.
Actual: validator errors on the unresolved optional native package.

How verified

• cd packages/pi-fff && bun run typecheck — clean.
• bun test test/ — 18/18 pass (added mock for @ff-labs/fff-bun alongside @ff-labs/fff-node since bun-hosted tests now prefer the bun SDK).
• bun run format — no changes.

Not verified end-to-end against a real oh-my-pi install — that would need the pi validator in the loop. @dmtrKovalenko please smoke-test under omp before releasing.

Automated triage via Gustav. Honk-Honk 🪿

[gustav-fff]

[triage-bot] CI note: Spell Check with Typos fails on crates/fff-core/src/bigram_query.rs:202 (simpliest → simplest). Pre-existing on main — same failure on the latest main run: https://github.com/dmtrKovalenko/fff/actions/runs/29052646755. Unrelated to this diff.

Honk-Honk 🪿

[dmtrKovalenko]

@gustav-fff iterate

[gustav-fff]

[triage-bot] DIRECTED: need a concrete direction — "iterate" is ambiguous. Candidates I see:

1. Drop the import type from @ff-labs/fff-node entirely (belt-and-suspenders vs. a static validator that doesn't grok import type). Trade-off: lose the shared type surface, would need to re-import from @ff-labs/fff-bun or packages/shared/fff-api.ts.
2. Remove the SDK cross-fallback in loadSdk() — on bun, falling back to @ff-labs/fff-node re-introduces the ffi-rs cost the PR is trying to avoid. Fail loud instead.
3. Test end-to-end under real oh-my-pi (need a repro command from you — I don't have omp).
4. Something else entirely.

Which one, or all?

Honk-Honk 🪿

[gustav-fff]

[triage-bot] DIRECTED: iterated on option 2 (drop the cross-runtime fallback). Pushed 24b02ed.

loadSdk() now imports only the runtime-appropriate SDK — no try/catch fallback. Rationale: on a bun host, falling back to @ff-labs/fff-node re-introduces the ffi-rs load cost this PR is meant to avoid, and silently masks packaging bugs (wrong SDK installed → we want a loud error, not a slow success).

Diff: -20 / +5 in packages/pi-fff/src/index.ts. Tests 18/18 pass.

Left options 1 (drop import type entirely) and 3 (real oh-my-pi smoke test) untouched — 1 is speculative without a validator that mis-handles import type, 3 needs a repro command from you. Say the word if you want either.

Honk-Honk 🪿

[dmtrKovalenko]

@gustav-fff hello - fix the CI

and verify that it works with oh-my-pi on whatever machine you are

[gustav-fff]

[triage-bot] DIRECTED:

CI fix: pushed 23d76af — simpliest → simplest in `crates/fff-core/src/bigram_query.rs:202`. Same fix as main (branch predates it); `typos .` clean locally now. The other CI slowness on this PR is unrelated to the diff — pi-fff only touches `packages/pi-fff/` + `packages/shared/` and doesn't exercise the Rust/Neovim/Python matrices.

oh-my-pi verify: no omp on this machine — closest available runtime is `pi` (earendil-works) which is node-shebanged here (`#!/usr/bin/env node`, so `detectRuntime()` returns `node`).

What I verified:

• Extension registers under bun (bun -e harness): tools=["ffgrep","fffind"], commands=["fff-mode","fff-health","fff-rescan"], session_start fires cleanly. loadSdk() resolves @ff-labs/fff-bun — no ffi-rs pulled in.
• import type from @ff-labs/fff-node erases: tsc --noEmit clean; the compiled JS has zero references to @ff-labs/fff-node, so any static extension validator walking the JS graph won't hit ffi-rs.
• packages/pi-fff typecheck + bun test test/ (18/18) still green.
• Cross-runtime dynamic import defeats static resolution: verified loadSdk() returns the correct SDK per detectRuntime(), no static string mentions of the other SDK path.

What I could NOT verify: end-to-end under the real oh-my-pi validator — omp isn't installable here without a repro command. If you can share the omp invocation that reproduced the original failure on `main`, I can rerun it against this branch.

Honk-Honk 🪿

[dmtrKovalenko]

okay @gustav-fff now rebase

[gustav-fff]

[triage-bot] DIRECTED: rebased on origin/main. Head is now be23eb5 (was 23d76af).

• Dropped 23d76af fix(typo): simpliest -> simplest — already upstream (patch contents identical, cleaned by git rebase).
• Kept the two pi-fff commits: 14a756f (isomorphic runtime + lazy load) and be23eb5 (fail loud on wrong-runtime SDK).
• Pushed with --force-with-lease.

Honk-Honk 🪿