Make --fetch-preconnect establish startup connections in Home subprocesses

The unchanged Bun fixture js/web/fetch/fetch-preconnect.test.ts now passes all 12 cases in the routed corpus realm, but strict production execution exposes an independent CLI/runtime gap in the --fetch-preconnect case.

Reproduction with the current Home Debug executable:

HOME_NATIVE_VM=1 HOME_CORPUS_FULL_VM=1 home-debug test packages/runtime/test/bun-corpus/js/web/fetch/fetch-preconnect.test.ts

Results: 11 pass, 1 fail. The child launched as home-debug --fetch-preconnect=http://localhost:<port> --eval Bun.sleep(64) exits without establishing the socket, and the unchanged upstream test reaches its 5,000 ms deadline. Pinned Bun 4982b91e3 passes 12/12.

The CLI flag is parsed into runtime_options.preconnect, and bun.js.zig calls AsyncHTTP.preconnect; diagnose why the startup connection does not reach the listener in Home, fix production behavior, and verify the unchanged strict fixture. Do not increase the test timeout or synthesize the socket.

Fixed and pushed in a142501 (fix(runtime): honor cli preconnect in direct vm). Root cause: Home’s direct VM boot parsed --fetch-preconnect into runtime_options.preconnect but bypassed Bun’s Run.boot preconnect hook. The URL validation/scheduling path now lives in AsyncHTTP.preconnectFromCli and is called from both boot paths. Verification: malformed URL exits 1 before eval; a real local TCP listener accepts the startup connection; unchanged upstream fixture hash matches pinned Bun; Debug and ReleaseSafe strict each pass 12/12; routed each pass 12/12; runtime units 1821 pass, 19 skip, 0 fail. No fixture or deadline changes.