WebAssembly Core 2.0: implement bulk memory and passive segments

[chrisbbreuer]

Parent: #263
Depends on: #271
Roadmap: #142, #134

Implement bulk-memory-owned segment forms and instructions failure-atomically.

Acceptance:

• Decode and validate DataCount plus active, passive, and declarative data/element segment encodings at the pinned revision.
• Implement memory.init, data.drop, memory.copy, memory.fill, table.init, elem.drop, and table.copy.
• Preserve overlap semantics, bounds/trap ordering, dropped-segment state, and link-time atomicity.
• Integrate passive reference segments with precise GC and cross-instance tables.
• Add JavaScript API and focused binary/runtime coverage with stable disabled-feature diagnostics.

Child issue map

• WebAssembly bulk memory: decode and validate segments and instructions #276 — binary decoder and validator surface
• WebAssembly bulk memory: execute memory operations and passive data lifecycle #277 — memory operations and passive data lifecycle
• WebAssembly bulk memory: execute table operations and passive reference segments #278 — table operations, passive references, GC, and JavaScript synchronization

Implementation order

Land #276 first so both execution children consume one validated IR. Then #277 and #278 can proceed independently; close #272 only after both runtime paths and the combined API evidence are complete.

[chrisbbreuer]

Bulk memory is complete through #276/#277/#278. The full DataCount/segment binary surface, validator, failure-atomic memory lifecycle, exact overlap/drop/bounds behavior, typed table lifecycle, cross-instance identity, JavaScript synchronization, and precise-GC barriers are on main. The focused Wasm suite passes 159/159 at 4c61bd90; the final cross-instance witness passes 3/3 at 66237d21; README/docs are current at 03d46ae9. The public benchmark remains the validated July 17 1,540-sample matrix because these paths are outside its workloads.