[Bug]: pi-fff cannot load under omp (Oh My Pi) — Bun-compiled pi runtime misdetected as 'bun'

## Bug: pi-fff fails to load in omp (Oh My Pi) — Bun-compiled pi runtime misdetected as "bun"

### Summary

`@ff-labs/pi-fff` (the pi extension behind fffind/ffgrep) fails to load inside **omp (Oh My Pi)**, a coding harness that embeds `@earendil-works/pi-coding-agent` compiled into a single Bun binary. Every `fffind`/`ffgrep` call errors with:

```
ResolveMessage: Cannot find module '@ff-labs/fff-bun' from '~/.omp/plugins/node_modules/@ff-labs/pi-fff/src/sdk.ts?mtime=...'
```

The module **is installed and complete** — it just cannot be resolved at runtime.

### Environment

- omp (Oh My Pi), plugin installed via its `~/.omp/plugins` mechanism (bun.lock, `@ff-labs/pi-fff@0.10.3`)
- Linux x64, glibc
- Plugin dir: `~/.omp/plugins/node_modules/@ff-labs/{pi-fff,fff-bun,fff-node,fff-bin-linux-x64-gnu}` — all present, freshly installed

### Root cause analysis

`pi-fff/src/sdk.ts` chooses the SDK at runtime:

```ts
function detectRuntime(): "bun" | "node" {
if (typeof (globalThis as { Bun?: unknown }).Bun !== "undefined") return "bun";
if (typeof process !== "undefined" && (process as { versions?: { bun?: string } }).versions?.bun) return "bun";
return "node";
}
// const pkg = detectRuntime() === "bun" ? "@ff-labs/fff-bun" : "@ff-labs/fff-node";
```

omp is a **Bun-compiled standalone binary** (its logs show the embedded fs: `/$bunfs/root/packages/coding-agent/src/cli.js`), so `globalThis.Bun` exists. `detectRuntime()` therefore returns `"bun"` and the extension dynamically imports `@ff-labs/fff-bun`, whose entry is **TypeScript source**:

```json
// @ff-labs/fff-bun/package.json
"main": "src/index.ts",
"exports": { ".": { "import": "./src/index.ts", "types": "./src/index.ts" } }
```

omp's module resolver (Node semantics, error type `ResolveMessage`) cannot load `.ts` files under `node_modules` — the same failure Node 24 reports as `Stripping types is currently unsupported for files under node_modules`. The import fails, reported as `Cannot find module`.

The JS-compiled sibling `@ff-labs/fff-node` (`main: dist/src/index.js`) **would work fine**, but it is never selected because the runtime is misdetected as bun.

### Evidence

- `bun -e "import('@ff-labs/fff-bun')"` from the plugins dir: **succeeds** (plain Bun handles TS fine)
- `node -e "import('@ff-labs/fff-bun')"`: fails with `Stripping types is currently unsupported for files under node_modules` — the package is found, the entry type is the problem
- Restarting omp does **not** help (structural, not a stale-cache issue)
- omp's own log shows the same resolver limitation for another external package: `ResolveMessage: Cannot find module 'fastembed/package.json' from '/$bunfs/root/packages/coding-agent/src/cli.js'`
- Native pi (`@earendil-works/pi-coding-agent`, engines `node >= 22.19.0`) has no `globalThis.Bun`, detects `"node"`, uses `fff-node` — works fine. This is specific to Bun-compiled hosts of pi.

### Suggested fixes (any would unblock)

1. **Publish a compiled-JS entry for `@ff-labs/fff-bun`** (or point `main` at a `dist/` build) — most robust, mirrors `fff-node`.
2. **Make `detectRuntime()` probe actual loading capability** instead of `globalThis.Bun` (e.g. try importing the JS build first, or check `process.versions.bun` only — note a Bun-compiled binary *does* set `process.versions.bun` too, so neither global probe is reliable here; an env-var override or capability probe is needed).
3. **Expose an override** (env var like `FFF_SDK=node`) so Bun-compiled hosts can force the Node SDK.

Happy to provide more logs or test a fix if useful.

Start in pi-fff/src/sdk.ts and inspect the runtime selection and dynamic SDK import, then compare @ff-labs/fff-bun/package.json with the compiled @ff-labs/fff-node entry. Reproduce the import under omp or Node, and verify the chosen fix lets fffind and ffgrep load in omp while preserving the native Node behavior.

Written by the indexing model from the issue text.