fix(ts): frame source and config in persistent cache keys

The persistent TS emit cache currently hashes source bytes, then an optional | separator and the config blob. This is not injective: source "1", config "2;" and source "1|2;", empty config both hash the byte stream "1|2;". A cached compile can therefore return JavaScript for a different source or compiler configuration. The old scheme also aliases source "a|b", empty config with source "a", config "b".

Acceptance:

• Use a versioned, unambiguous framing of source and config bytes so old disk keys cannot be mistaken for new ones.
• Prove distinct keys and actual cache misses for delimiter and empty-config collisions, including a TS driver compile path.
• Compile the shipped ts_cache module and run its public tests on the pinned Zig 0.17 and CI Zig 0.18 in Debug and ReleaseFast.
• Preserve existing cache/driver/Program tests; do not treat this scoped fix as full compiler parity.

Related: #884 (dual-toolchain source coverage), #66 (runtime/TS parity).

Pushed a441cc5 directly to origin/main as glennmichael123, with no coauthors and exactly four files.

The key is now SHA-256 over a version tag plus little-endian length-framed source/config bytes. Old disk keys are unreachable, so a collision under the old concatenation cannot return stale JavaScript. Public cache tests cover delimiter, empty-config, binary-byte and actual lookup separation; a TS driver regression compiles two valid source/config pairs that previously shared one key.

Verification under the unchanged 3,840 MB guard, one heavy process at a time: standalone shipped static library plus 18/18 tests on Zig 0.17.0-dev.2163 and Zig 0.18.0-dev.146 in both Debug and ReleaseFast; full pinned TS driver 214/214; full pinned TS Program 321/321; focused TS driver 4/4 on Zig 0.18. Zig fmt --check and staged diff --check passed. Maximum observed tree footprint was 2,188 MB. Remote main tip was verified as a441cc5. This closes the cache-key collision, not broader TS or Bun parity.