Card L-D2b (DIAGNOSTIC ONLY: debugger-forced, never a candidate) - written 2026-09-26 17:06:26 -0700 (clock-read) BEFORE running
Function: _widget_instance_render_recursive, source rr2.c unchanged. Follow-up of L-D2.
Intervention: at the LAST sort of the loop ADD before lowering, site 0x107105ab (at 0x107105ae EAX = input-1 entry =
the address load), window (k-1,k) hit 79 (s2_rr2 observation: in1 k06 0x1c008, in2 k02 0x19300), FORCE
[EAX+0x10] := 0x10008 (the load key that id(t_183) & 3 == 0 would give). Nothing else.
Prediction: sorted [SR 0x19300, load 0x10008] -> builder in1 kind 1 (SR) -> COMMON -> base = SR IV, index = address
-> +0x78 `mov dx,[ecx+eax]`, render_recursive section_infos_equal to January, no other function changes - 75%.
20%: another consumer of the entry key (e.g. the node hash stored at +0x10 by 0x1070ddcb, CSE lookup) changes a
different decision. 5%: another later sort.

OUTCOME (appended 2026-09-26 17:06:45 -0700): PREDICTION HELD. Forced object (work/fd2b_rr2): only
_widget_instance_render_recursive differs from the stock replay, and it is section_infos_equal to January (752 B).
=> the key comparison at the last pre-lowering sort (0x107105ab) is causally sufficient: with the address load's key
at 0x10008 (id(t_183) & 3 == 0) the SR IV sorts first and the builder emits January's [ecx+eax]. Together with L-D1
(the swap route) both decoded routes reproduce January exactly; nothing else in the function depends on them.
