Port Bun BuildArtifact content hashing with canonical module paths

Tracks a focused remaining item from #66.

The unchanged packages/runtime/test/bun-corpus/bundler/bun-build-api.test.ts now gets past its generated module-comment path snapshot, then fails the BuildArtifact properties: hash snapshot:

• actual: home-88424
• expected: est79qzq

Home currently constructs adapter BuildArtifact.hash values from output length/path. Bun computes an xxHash64-based linker hash over canonical module identities, part ranges, output templates, public paths, generated pieces, sourcemaps, and imported chunk hashes, then formats it with its eight-character truncated base32 alphabet.

A production Home Bun.build probe returns a real native hash (r00pwt21) for the mirrored fixture, but that still differs because the native hash sees packages/runtime/test/bun-corpus/... while upstream Bun hashes test/.... The correct fix must preserve Bun canonical module identity through the mirrored corpus/native bundler boundary and expose the native artifact hash. Do not special-case the fixture or expected hash, and do not rewrite the upstream snapshot.

Fixed and pushed in e6e7aab.

Home now preserves Bun corpus module identities through a native onResolve/onLoad bridge, runs the real production bundler, and serializes native BuildArtifact metadata back into the corpus realm. This removes the synthesized home-* hash and produces Bun-compatible hashes including est79qzq and 7gfnt0h6, while retaining sourcemap relationships and loader/kind/MIME metadata.

Validation:

• zig build debug -Denable_jsc=true passed.
• The unchanged bundler/bun-build-api.test.ts passed 45 tests, 0 failed, 0 unsupported, with 3 upstream todos.
• The run passed with the parent NODE_PATH explicitly unset.