E36: over ten iterations FPO++ collapses pi0.5 and DPPO barely moves it

[tactino]

E36 was pre-registered at bb9d36b, before any run. It runs pi0.5 on LIBERO-10 task 8 for ten iterations under E32's FPO++ arm (two server seeds) and E25's DPPO. Fifty-episode evaluations at iterations 5 and 10; the untrained policy scores 30.9 ± 3.6:

run	iteration 5	iteration 10
fpopp-s7	5 / 50	no checkpoint
fpopp-s8	0 / 50	no checkpoint
dppo	28 / 50	20 / 50

• V1 and V2 pass.
• P1 fails for the FPO++ runs, and the fault is mine. The harness kept E32's 12-hour timeout on the clients. That fits two iterations, not ten iterations of about 80 minutes each, so the tenth learn step was killed mid-flight and no iteration-10 checkpoint was written. DPPO completed.
• P2 cannot be read as registered. Both FPO++ runs are at or below the collapse line at iteration 5, and their training success was 0 over their last iterations. The one allowed restart was not used; it would cost about 13 GPU-hours to read a number the rest already gives.
• P3 holds, on the line: DPPO at 20/50, three standard deviations below the untrained mean. Its approx_kl stayed around 2e-7, and the expert moved 0.24%.

What the logs show: FPO++'s flow-matching loss on the policy's own fresh samples rose from 0.11 to 114 / 407, and its clipped fraction climbed to 75–99%. The policy came apart, the same shape as E37 on square. Both ran with FPO's own defaults that FPO++ does not share: rewards ×10, per-epoch value refresh, one learning rate, no clipping. E39 (on #91) is testing FPO++'s full settings on square first.

Figure: pi0-policy · DPPO stays "holds". pi0-policy · FPO held for one update (E32) and collapsed within five iterations here. Its cell's status and note will change with the next figure update.