chore: upgrade bun runtime to 1.4.2

[FNDEVVE]

Supersedes #1481 (branch renamed to chore/upgrade-bun-1-4-2; GitHub cannot retarget a fork PR head, so that PR was closed).

Summary

Upgrades the pinned Bun runtime from 1.3.14 to 1.4.2 across CI workflows, package definitions, and the lockfile.

Changes

• Pi Network Tests: Bun 1.4 attaches an internal connection tracking listener (setupConnectionsTracking) to node:http.Server instances upon creation. Updated apps/pi-extension/server/network.test.ts to verify listener cleanup relative to the initial listener count (server.listenerCount("listening") === initialListening) rather than assuming zero absolute listeners.
• Root Dependencies & Lockfile:
  • Bump bun-types to ^1.4.2 in root package.json.
  • Bump @types/bun to ^1.4.2 in packages/ui/package.json so the declared range matches the runtime.
  • Add Bun 1.4.2 packages to minimumReleaseAgeExcludes in bunfig.toml.
  • Regenerate bun.lock with @types/bun@1.4.2, bun-types@1.4.2, bun@1.4.2, and @oven/bun-*@1.4.2 platform packages. The lock's previously stale @oven/bun-*/bun entries (a peer-dependency resolution of @plannotator/server's bun: >=1.0.0) are re-resolved against the registry; bun install --frozen-lockfile reports no changes.
• Workflows & Tooling:
  • Update bun-version: 1.4.2 across .github/workflows/{test,release,deploy,guides-show-deploy,security}.yml.
  • Update DAST configuration in .github/workflows/dast.yml with BUN_VERSION: 1.4.2 and TARGET_IMAGE: oven/bun:1.4.2-slim@sha256:cb3bbbb08e13a4a2ff400f24c7a2a1d5efa83f6ef8544d52d95a519631e2fc61 (index digest read from the registry via docker buildx imagetools inspect; the same command reproduces the digest pinned for the previous tag byte-for-byte).
  • Update Renovate setup-bun rule description in .github/renovate.json.
• Test Hardening:
  • Avoid race condition in waitForFile in packages/server/agent-terminal.test.ts by checking statSync(path).size > 0.
  • Add explicit finally config cleanup and 15s timeout to packages/server/api-404-guard.test.ts to prevent test timeout and state leakage under heavy test concurrency.
  • Give defaultRunCommand a 30s timeout in packages/server/uninstall.ts so the Windows PowerShell path does not trip under load.

Verification

All checks run locally under Bun 1.4.2 (macOS arm64):

• bun run typecheck: Passed (all 10 project tsconfigs emit zero diagnostics)
• bun run --cwd apps/guides-show build:viewer && bun run --cwd apps/guides-show sync:manifest && bun run --cwd apps/guides-show check:budgets && bun run --cwd apps/guides-show check:manifest: Passed (budgets within limit, worker import-free, manifest in sync)
• bun run --cwd apps/review build && bun run build:hook && bun run build:opencode: Passed
• Compiled binary check (bun build apps/hook/server/index.ts --compile): Successfully built and executed
• Full test suite (CI="" bun test): 4,346 passed, 912 skipped, 0 failed across 469 files (17,491 assertions)
• bun install --frozen-lockfile: Succeeded with no changes

[backnotprop]

Rebased onto current main (d74c289d, post-#1501 dependency refresh) and re-verified everything under the official Bun 1.4.2 binary. Head is now f7ebbc0f (force-pushed with lease).

What the rebase changed

• Conflicts were limited to package.json (kept main's 0.27.13 + chore(deps): bun minor+patch group (holds: @types/vscode, pi-coding-agent, katex) #1501's dependency refresh, took this PR's bun-types: ^1.4.2 over main's ^1.4.0) and packages/ui/package.json (kept main's refreshed devDeps, took @types/bun: ^1.4.2).
• bun.lock was regenerated from scratch with Bun 1.4.2 itself (rm bun.lock && bun install), never with 1.3.x. Net delta vs main is small (53+/29-): bun/bun-types/@types/bun/@oven/bun-* → 1.4.2, root semver 7.8.0→7.8.5 (pi-coding-agent keeps 7.8.0 nested — the chore(deps): bun minor+patch group (holds: @types/vscode, pi-coding-agent, katex) #1501 hold is intact), a few nested @types/node@26.4.1/undici-types@8.3.0/minimatch@10.2.6 entries. All within declared ranges. katex stays 0.16.47; exactly one @codemirror/state@6.7.2. bun install --frozen-lockfile under 1.4.2: no changes.
• Everything else (workflows, bunfig excludes, test adjustments, uninstall.ts) applied cleanly.

Verification (all under the official 1.4.2 darwin-aarch64 binary)

Check	Result
bun run typecheck (incl. vendor.sh, 9 tsconfigs)	✅ pass
Full bun test (temp PLANNOTATOR_DATA_DIR)	✅ 4444 pass / 920 skip / 0 fail (5364 tests, 476 files)
Baseline bun test on main under 1.3.14	✅ green (after vendor.sh, as CI does) — zero delta
build:review → build:hook → build:opencode → build:pi → build:marketing → build:portal	✅ all pass, tree clean after
bun build --compile binary smoke	✅ --version, review --help shows --base/--diff-type (#1484 preserved), live review /api/diff (rawPatch), live annotate + /api/feedback decision POST → clean exit with feedback on stdout, unknown subcommand exits 1, sessions, guide list
bun run package:vscode	✅ vsix packaged
check:manifest (after build:viewer) + check:budgets	✅ in sync, worker import-free — no regeneration needed
Hook bundle invariants (#1501)	✅ one @codemirror/state copy in index.html, only 0.16.47 katex version string
oven/bun:1.4.2-slim DAST digest	✅ matches registry (sha256:cb3bbb…fc61) byte-for-byte
release.yml matrix	✅ all 6 setup-bun pins → 1.4.2; all 6 plannotator + 6 paste targets compile from the same pinned bun; smoke-binaries legs unchanged
Paste-service binary (targets/bun.ts) compiled + POST/GET round-trip	✅ (62.2 MB, ~1.2 MB smaller than shipped)
Install scripts	✅ no hardcoded bun version anywhere (binaries are prebuilt; comments only)
uninstall tests + compiled uninstall --dry-run	✅ 44 tests pass; dry-run lists, removes nothing

⚠️ One real distribution finding: +40 MB per main binary (+33%)

bun build --compile with the exact release flags produces 159,713,778 bytes vs the shipped v0.27.13 plannotator-darwin-arm64 at 119,900,642 — and the delta is Bun's, not ours:

• Same worktree compiled with 1.3.x → 122.8 MB; with 1.4.2 → 159.7 MB. The non-compiled JS bundle is byte-comparable (58.95 vs 58.66 MB); the growth is entirely in the standalone __BUN payload segment (58.9 → 96.7 MB).
• Minimal repro: a with { type: "text" } import of a 5 MB pure-ASCII file embeds once under both versions. Append one non-ASCII character and Bun 1.4.2 embeds the content twice (67.3 → 72.4 MB). Our two embedded HTML apps (22.7 + 18.2 MB, non-ASCII content) are exactly the ~38 MB being doubled.
• Correctness is unaffected (all smoke tests pass; the imported text round-trips), and --sourcemap=none doesn't help. 1.4.2 is the newest release, so there's no patched version to jump to.

So expect every release binary (all 6 platforms) to grow ~30% until upstream fixes the double-embedding. Worth filing against oven-sh/bun with the repro above; whether that's acceptable to ship in the meantime is a maintainer call — everything else here is green.

Other notes for the record

• Lockfile format: the 1.4.2 regen writes lockfileVersion: 2. Verified that Bun 1.3.14 cannot read it (warn: Ignoring lockfile, and --frozen-lockfile then fails). CI is fully repinned so it's fine there, but contributors must upgrade their local bun to ≥1.4 after this merges — a plain bun install on 1.3.x would churn the lockfile back.
• bunfig.toml excludes: adding bun/bun-types/@types/bun/@oven/bun-* to minimumReleaseAgeExcludes is required right now (1.4.2 is younger than the 7-day gate — the regen confirmed it resolves), but it permanently exempts the bun toolchain from the supply-chain age gate. Consider removing those entries once 1.4.2 ages past the window, or annotating them like the opencode ones.
• Test adjustments assessed, none weaken coverage: network.test.ts counts listening listeners relative to the count captured right after createServer() (Bun 1.4 attaches an internal connection-tracking listener at creation) — leak detection is preserved and the assertion is version-agnostic; agent-terminal.test.ts waits for a non-empty file (closes a partial-write race); api-404-guard.test.ts gains cleanup + an explicit 15s timeout.
• uninstall.ts: the one production change doubles defaultRunCommand's kill-timeout 15s→30s. That guard wraps plugin-manager removals and the Windows PowerShell PATH edit/restore scripts (Add-Type compile + SendMessageTimeout can legitimately exceed 15s under load); the sentinel-echo proof-of-write logic already tolerates a timeout, no test pins the constant, and worst case uninstall waits 30s per hung command. Low risk, arguably a fix 1.3 needed too.