refactor(browser-host): investigate extracting first-party code from Wasmer patches

[f0rr0]

Deferred follow-up, explicitly parked outside the repository simplification acceptance gate.

Oliphaunt-specific browser execution currently lives partly inside patches to wasmer-js, notably src/bindings/wasix-ts/host/patches/0007-wasmer-js-run-oliphaunt-direct.patch and its follow-up patches. This makes changes to our own implementation depend on rebasing vendor patch context.

Investigate moving that implementation into the planned runtimes/wasix-browser-host project, retaining only necessary upstream hooks and correctness fixes as vendor patches. The already-planned project relocation/build ownership can proceed without this deeper extraction.

• Reconcile current main and related work in Follow up patch consolidation: signal semantics, performance profiling, and qualification #201 and audit: track PostgreSQL, SDK, WASIX, extension, and tooling follow-ups #203 before implementation; local planning checkout observations are not claims about merged fixes.
• Map private/public Wasmer APIs used by the direct instance, filesystem and streaming integration; demonstrate a minimal viable extraction before committing to an interface redesign.
• Keep browser module loading, raw streaming/backpressure, cancellation, error recovery, storage durability and shutdown behaviour intact.
• Compare maintained vendor delta, build dependencies and output size; abandon extraction if it merely introduces a second wrapper framework.
• Build and exercise the browser package from a clean consumer; preserve pinned source/artifact identity and licensing.

No Wasmer family upgrade, new browser SDK, or upstream PR submission is implied. Coordinate dependency-family changes with the separate alignment follow-up.