feat(planning): explain and trace planning decisions

docs/benchmark/README.md

@@ -4,10 +4,11 @@ Open the deployed application at `/benchmark` on the reference phone. Tap
 **Run benchmark**, wait for the five scenarios to finish, then tap **Copy
 report** and save the tab-separated output with the date and build identifier.
 
-The harness measures preparation, asynchronous calculation, and total wall
-time separately. It records the outcome, last completed quality stage,
-placement count, and determinism between repetitions. `PlanningIncomplete` is
-not a conflict: its last completed stage and incumbent are retained.
+The harness measures preparation, planning-to-outcome latency, later trace
+delivery, and total wall time separately. It records the outcome, last
+completed quality stage, placement count, determinism, trace status, and trace
+candidate count. `PlanningIncomplete` is not a conflict: its last completed
+stage and incumbent are retained.
 
 ## Protocol
 
@@ -24,5 +25,7 @@ not a conflict: its last completed stage and incumbent are retained.
   hardware limitations. No mobile-device measurement is claimed by the source
   tree until a human records it here.
 
-The browser page uses the same `planLeave(request)` operation as the calendar
-and adds no solver or backend dependency.
+The browser page uses the same `createPlanningCalculation(request)` context as
+the calendar and adds no solver or backend dependency. The ten-second release
+ceiling applies to planning latency; trace delivery is reported separately and
+cannot replace a valid planning outcome.