Port Bake bun:app response bridge and generated error builtin

Context

The Bake development server/HMR port in #553 now serves HTML routes, performs real incremental HMR, and discovers filesystem framework routes. While validating framework route execution against Bun 4982b91e3702094330f3be3883354c52b8c01323, two adjacent runtime bridge gaps remained:

1. A framework route using the global Response constructor is transformed to import { Response } from bun:app, but the server HMR loader cannot load that bundled module (Failed to load bundled module 'bun:app'). Calling new globalThis.Response(...) works and proves the framework route pipeline itself is functional.
2. The pinned generated bake.server.js references $ERR_SSR_RESPONSE_EXPECTED for an invalid server-render response, but Home does not yet install Bun's generated ErrorCode builtins, so the error path raises a ReferenceError instead of the intended diagnostic.

Scope

• Port the bun:app response/runtime bridge needed by Bake server bundles.
• Expose the generated $ERR_SSR_RESPONSE_EXPECTED builtin with Bun-compatible behavior.
• Add focused integration coverage using ordinary Response and the invalid-response diagnostic path.
• Preserve the pinned generated bake.server.js asset byte-for-byte rather than patching generated output.

Acceptance criteria

• Filesystem framework routes can return new Response(...) without using globalThis as an escape hatch.
• Invalid server-render return values produce Bun's expected SSR response error rather than a missing-global ReferenceError.
• Existing Bake production, development/HMR, JSC runtime, and non-JSC build gates remain green.

Related to #553 and tracked by #66.

Completed on main in 92715e738, authored and committed by Chris Breuer without coauthors.

What landed:

• Fixed BundleV2's hardcoded-module tag conversion. Home's pure-data alias shim uses a different enum layout from ImportRecord.Tag; the former backing-integer cast converted .builtin to .none, which made parser-generated bun:app imports enter the ordinary HMR dependency table. The conversion is now explicit, as it already was in the other resolver paths.
• Added bun:app alias coverage and changed the live framework route fixture from the globalThis.Response workaround to ordinary new Response(...). The route now resolves through HMR's builtin loader and the native Bake response constructor.
• Added a real invalid-return route and asserts that it produces an HTML 500, the intended message, and ERR_SSR_RESPONSE_EXPECTED, with no missing-global ReferenceError.
• Corrected the embedded server runtime's raw $ERR_SSR_RESPONSE_EXPECTED token. Investigation invalidated the original byte-for-byte acceptance assumption: the exact pinned Bun 4982b91e3702094330f3be3883354c52b8c01323 generated asset and local release binary also leave this builtin-only token in an ordinary eval program and raise ReferenceError. Home's minimal generated-asset correction materializes the intended coded Error contract instead of preserving that upstream defect.

Verification after the implementation:

• JSC home_rt: 1,808 passed / 19 skipped / 0 failed, 20/20 build steps.
• Bake production: 18/18.
• Bake development: 18/18, including HTML/client serving, HMR update + diagnostic recovery, plain Response, dynamic route params, and invalid response validation.
• JSC-disabled debug build: 5/5.
• Focused Pickier, Python byte-compilation, Zig formatting, generated-runtime contract checks, and git diff --check: clean.

The unsupported JSC-disabled unit-test link still retains the complete runtime extern graph and reports unresolved native symbols; the supported independent compiler build is green and this pre-existing test-link limitation is not counted as a passing gate.

This closes the bounded Bake bridge work. #66 remains open because whole-suite parity is still incomplete.