feat(server): wire Server.listen() through native HttpApi listener (kill-switch)

[kitlangton]

Summary

• When the effect-httpapi backend is selected, Server.listen() now delegates to HttpApiListener.listen() (native Bun.serve + inline WS upgrades) instead of routing through the Hono runtime adapter (Hono.fetch + createBunWebSocket).
• The Hono backend path is unchanged.
• New env var OPENCODE_HTTPAPI_LEGACY_LISTENER forces the effect-httpapi backend back through the Hono adapter as an escape hatch.

Why now

This is step 6a of the Hono deletion arc. Stacks on top of:

• refactor(server): extract Hono-coupled utilities to backend-neutral modules #25542 (utilities extracted to backend-neutral modules)
• feat(server): Server.openapi() backed by HttpApi spec, parity-checked against Hono output #25545 (Server.openapi() backed by HttpApi spec)
• feat(server): native HttpApi listener with Bun.serve + WS upgrade #25547 (native HttpApi listener PoC)
• feat(httpapi-listener): workspace-proxy WS forwarding #25594 (workspace-proxy WS forwarding in the listener)

Together those got the native listener to functional parity with the Hono path. This PR finally gives it production traffic — on dev / beta / local install channels where OPENCODE_EXPERIMENTAL_HTTPAPI already defaults on. prod / latest channels still go through the Hono path until the rollout is complete.

Kill switch

OPENCODE_HTTPAPI_LEGACY_LISTENER=1

When set, the effect-httpapi backend goes back through adapter.create(app).runtime.listen() (i.e. Hono is wrapping the HttpApi handler again). Has no effect when the Hono backend is already selected. The flag is documented in flag.ts next to OPENCODE_EXPERIMENTAL_HTTPAPI.

What's NOT in this PR

• Removing any Hono code. The Hono backend, middlewares, and routes are untouched. That's step 6b.
• Node adapter for the native listener. Bun-only for now; BunHttpServer.layer is the only path that gives us Bun.serve's path-based WS upgrade hook.
• Touching the --hono debug flag for Server.openapi() (kept for spec diffability).

Behavior diff for the native path

Concern	Hono adapter path	Native listener path
HTTP routing	Hono → HttpApi via webHandler	HttpApi webHandler directly
WS upgrade (PTY)	createBunWebSocket	Bun.serve#fetch → server.upgrade(...)
WS upgrade (workspace proxy)	WorkspaceRouterMiddleware → ServerProxy.websocket	resolveWorkspaceProxy → inline bridge in httpapi-listener.ts
mDNS publish	unchanged	unchanged
Server.url module export	unchanged	unchanged
listen({ port: 0 }) fallback	Bun adapter handles	start(4096) ?? start(0) (matches existing behavior)
Telemetry	opencode.server.backend only	adds opencode.server.listener=bun-native

Test plan

• bun run typecheck clean (13/13)
• bun run test test/server/ — 172 pass / 0 fail / 2 todo (covers the new httpapi-listener.test.ts workspace-proxy + PTY paths from feat(httpapi-listener): workspace-proxy WS forwarding #25594)
• Manual: run opencode serve on a dev channel and exercise the SDK end-to-end
• Manual: set OPENCODE_HTTPAPI_LEGACY_LISTENER=1 and confirm the Hono adapter path comes back (look for opencode.server.listener absent from the structured log)

[kitlangton]

Closing — redundant. The effect-httpapi backend already has full WS + proxy support via HttpApiProxy.websocket + workspace-routing middleware. The real fix is to swap adapter.createFetch for Effect's BunHttpServer.layer in Server.listen()'s effect-httpapi path. Replacement PR coming.