chore(wasmer): investigate dependency-family and backport consolidation

[f0rr0]

Deferred research, explicitly parked outside the repository simplification acceptance gate.

The browser host, embedded WASIX executor and concurrent postmaster use different Wasmer dependency families and patch sets. src/bindings/wasix-ts/host/source.toml documents that its Wasmer 6.1 / wasmer-wasix 0.601 family cannot be upgraded by replacing a single crate with the 7.2 / 0.702 family used elsewhere.

• Reconcile current main and Follow up patch consolidation: signal semantics, performance profiling, and qualification #201, audit: track PostgreSQL, SDK, WASIX, extension, and tooling follow-ups #203 and fix(windows): qualify Wasmer V8 after upstream drops Sys compiler support #208; preserve their correctness/platform findings rather than duplicating or silently closing them.
• Inventory exact host/compiler/libc/virtual-fs/virtual-net/WebC/wasm-bindgen pins and required deltas across all three hosts.
• Determine whether a common supported upstream family actually reduces maintained compatibility patches; record genuine platform constraints if it does not.
• Prove exception recovery, side modules, browser storage, postmaster fresh-exec/shared-memory/concurrency and supported Windows behaviour on a candidate family.
• Account for serialized AOT compatibility: rebuild/requalify affected producers and consumers; never relabel an old artifact as compatible with a new engine.
• Retire superseded backports only after equivalent upstream behaviour is demonstrated, and compare build/distribution cost.

No blanket version bump, new universal runtime abstraction, support reduction, or optimization removal is authorized by this issue. Coordinate with the separate browser-host extraction follow-up; either investigation may conclude that keeping a narrow existing fork is simpler.