InlineZig burndown: capability guard and error-flow snippets

[cuzzo]

Non-low-risk InlineZig cluster from the opaque-Zig hardening pass.

Sites:

• src/mir/lowering/capabilities.rb:612 with_block_bindings
• src/mir/lowering/capabilities.rb:1094 with_guard_fail_raise
• src/mir/lowering/capabilities.rb:1096 with_guard_fail_raise_flow
• src/mir/lowering/capabilities.rb:1103 with_guard_fail_exit
• src/mir/lowering/capabilities.rb:1105 with_guard_fail_exit_flow
• src/mir/lowering/capabilities.rb:1143 pre_fail
• src/mir/lowering/capabilities.rb:1204 with_guard_fail

Risk:

• These snippets mutate runtime error state, polymorphic flow state, or splice lock/capability binding code as raw Zig strings. They are control-flow and synchronization-sensitive.

Acceptance:

• Replace with structural MIR nodes/statements for runtime error assignment, flow-state assignment, guard-fail return/raise/exit, and capability binding materialization where complexity stays flat or improves.
• Preserve GuardFail/PRE behavior and BC-specific structured paths.
• Any retained InlineZig must have a concrete low-risk justification.

[cuzzo]

Progress in 4ce95dc: replaced PRE failure, GuardFail raise/exit setError calls, GuardFail raise/exit flow snippets, and ordinary with_guard_fail action bodies with structural MIR. This also fixed a behavioral bug where polymorphic GuardFail RAISE/EXIT could set .raise_no_commit and then be overwritten by a synthetic .ret_no_commit return. Remaining site: with_block_bindings, which aggregates sorted lock acquire and capability binding snippets; decomposing it cleanly requires structuralizing the lock-binding emitters rather than wrapping the raw block under another node.

[cuzzo]

Assessed after 8630980. Remaining with_block_bindings is not a simple local InlineZig removal: it aggregates ordinary lock aliases, shared/borrowed/restrict/view aliases, sorted multi-lock acquisition, and fallible retry/error dispatch. A partial Zig-only replacement would either break the BC/register VM path, or rename the opaque blob into a new node without exposing semantics.

Decision: keep #101 open. Clean removal should introduce a dedicated structural WITH acquire/materialization node consumed by both Zig and BC emitters, with explicit fields for sorted acquire entries and FallibleClauseFact dispatch. That is the route that can reduce overall complexity; a one-off string split would increase it.