feat(WordRAM): retain explicit realization witnesses through the existing Backend #2391

Bounded infrastructure milestone under #2205/#2213, motivated by the fixed-resource Karger consumers in #2292 and KargerMinCutAbstract. Coordinator codex-root-2205-20261101; worker /root/roadmap_pcp will record its branch before edits.

At main fca53e43, Realizes existentially quantifies scratch size, exchange factor and emitter. Witness.scratchSize, factor and code choose them, and Certificate/Backend retain only that existential proof. Correctness and uniform existential bounds are sound, but supplying another proof of the same proposition cannot select a particular implementation or establish its concrete register/factor bounds. This is separate from the old Karger return routine's in-place ABI. Existing Refines carries explicit code, but current conversion/module entrypoints return to the chosen witness. Held #2267/#2273 do not supply a missing explicit carrier and remain held.

Extend/refactor the existing realization contract and the single Certificate/Backend path so a supplied data witness retains its scratch size, factor and emitter. Reuse the same execution/whole-memory/frontier/frame contract; do not add another semantics, compiler, parallel Backend or unrelated duplicate predicate. Keep an honestly existential choice-based construction for existing clients that need no concrete bounds. Preserve their public claims and migrate affected packaging in the same change.

First acceptance boundary:

• Retain explicit witnesses for the existing read/write/allocDirty/alloc primitives, reusing their proofs. The inspected constructions have proposed (scratch, factor) values (0,1), (0,1), (0,1), (2,4); verify rather than assume these.
• Route the existing alloc-two/write-seven/read client through the same generic Backend with proved concrete projections/code identities. The proposed family has seven registers and factor four. Check the actual full result/memory/frontier law and relevant zero-width/empty-allocation cases; argument installation remains an explicitly uncharged body calling convention.
• Keep existing existential Backend clients working without implying that their chosen witnesses have these concrete values. Explain representative before/after use and update affected manual/API documentation.
• Validate affected clients and all required checks; obtain independent outside-authoring-fleet correctness/API review of the new public definitions and statements. Assess abstracts; do not change their statements.

This milestone does not certify Karger's fixed 16/22/24-register endpoints, migrate all glue/bind/loop/random constructors, solve register reuse, or complete #2205. Those remain explicit follow-ups tied to real migration clients. Stop and report if the implementation requires broader architectural changes than retaining the existing contract's witnesses.

AI-assisted coordination and implementation; no human or integration approval is implied.