fix(spawn): resolve bun executable with PATH fallback

[bjb2]

Closes #6.

The bug

Reported by Axel on macOS. Starting the telegram bridge crashed with:

Error: ENOENT: no such file or directory, posix_spawn '/Users/axelneff/.bun/bin/bun'

That path is ~/.bun/bin/bun — the default install location for the official Bun installer. But the file isn't there. Most likely: Axel installed Bun via Homebrew (or asdf/mise/proto) after the deck started, and the original ~/.bun/bin/bun was gone or moved. The deck server captured the old path at boot via process.execPath and kept using it for child spawns.

Root cause

Two spots in the server spawn Bun child processes using process.execPath directly:

File	Use
apps/server/src/bridge-supervisor.ts:102	Spawns the telegram bridge subprocess
apps/server/src/index.ts:242	scheduleRestart re-execs the deck server

process.execPath is the path to the binary that started the current interpreter — captured AT PROCESS START, not "wherever bun lives now." Bun.spawn does NOT search PATH for cmd[0]; it goes straight to posix_spawn / CreateProcess and ENOENTs when the captured path is dead.

Fix

New apps/server/src/runtime-bun.ts with resolveBunExecutable():

1. Try process.execPath first — fast path, correct for normal users.
2. Fall back to Bun.which("bun") — searches PATH the way the user's shell would, finds wherever Bun lives now.
3. Throw a clear actionable error mentioning both attempts if neither resolves.

Memoized for the process lifetime (a working Bun binary doesn't move mid-process). Both spawn sites route through the resolver.

Verification

• 4 new tests covering: existing-path returns, memoization, stale-execPath fallback to Bun.which, both-missing throws with clear error
• Full server suite still green: 177/177 pass (was 173)
• Typecheck across all 4 packages: clean

Files touched

apps/server/src/runtime-bun.ts          (new)
apps/server/src/runtime-bun.test.ts     (new)
apps/server/src/bridge-supervisor.ts    (use resolver)
apps/server/src/index.ts                (use resolver in scheduleRestart)

Out of scope

• Periodically re-validating the cached path mid-process (a bun binary that moves DURING a deck run is too rare to engineer for — just restart the deck)
• Bridge UI polish to surface the resolution failure more clearly than the raw posix_spawn error (the new error message is already actionable; UI work is separate)