Handoff: Complete local suite validation for the current UrlProtocol Clock callback head

RE-VERIFY: Written 2026-10-21T07:29:31.819093+00:00. This is a write-time snapshot. Recheck https://github.com/CodexCoder21Organization/UrlProtocol/pull/740 with gh pr view before acting, then inspect ps -eo pid,args -ww and /proc process working directories before starting a complete suite.

Design decisions, 2026-10-21

• User ruling: "The rule from round 6 stands: no silent use of an earlier time."
• User ruling: "Reusing completedTime is acceptable only where the code can prove that no time can have passed since that sample. A callback boundary cannot prove that. So inside a callback, an action that needs the time takes a fresh Clock read."
• User ruling: "Keep the K1 property: no Clock read while a registry guard or persistence ownership is held."
• "No merge, enqueue, check re-request, publication or deployment."
• Run tests with --local. Keep existing test bounds and iteration counts. Leave the separately tracked storage-callback removal/restart issue alone.

Mission and observed mechanism

The owner reported that https://droplets.wasmserver.com/ "is super unreliable, frequently rendering various errors/notices due to bugs in UrlResolver or UrlProtocol or something else" and asked for the underlying root cause to be fixed; the ContainerNursery route stops the WUI after 5 idle minutes, so most human visits are cold starts.

This lane addressed round 7 of the presence freshness work. A Clock callback paused before entering runIfActive reused completedTime from before that pause. Both unchanged reviewer scenarios record contact 1000 after ManualClock moves to 301001; one also observes remaining duration 300000 instead of zero. Source callbacks now take a fresh read before lifecycle admission, and repeated source callbacks report a complete Clock/depth message before a third read. Prepared ownership scopes still reuse their established time without caller reads. Storage messages are unchanged. Fresh UrlResolver and ContainerNursery inventories found no checked-in production Clock that re-enters the registry.

Completed validation

• Each reviewer pause scenario is red 3/3 at requested head 437fd2ef55726e7ccb6f3ffc4f2974ae5c1c3ecc, green 10/10 first attempt after the change, and red 3/3 with the production source restored to its earlier version.
• The added bounded-read scenario is red 3/3 before the change and on reversal, green 10/10 first attempt. It asserts the full Clock/depth message, exact source-entry count, no action without time, and normal operation afterwards.
• Five expanded 53-case gates: 265/265 first attempt, zero histories, including the C21 250 cases.
• Cache observer: 1/1 first attempt, zero histories, entries 128 to 1.
• Three earlier Clock fixtures now use ordinary bounded callbacks; all prior persistence, removal, and duration assertions remain. Exact edits and reasons are in the findings.
• Nine earlier histories / 27 negative attempts are classified as baseline, reversal, or earlier fixture expectations. Final targeted checks have no histories.
• Rebase before the suite changed only two unrelated tests. Round-7 source and selected scenarios are byte-identical to the validated bytes.

Remaining complete-suite result

{ "state": "suite time cap", "exit": -15, "head": "c0ef1611c105acd663013b1657082910053ec469", "peakSingleJvmKiB": 3661836, "peakCombinedJvmKiB": 4275012 }

This is not a positive complete-suite result. The original slot wait admitted this lane only at about 07:05 UTC. The lane wall-clock limit arrived before the complete suite finished. Preserve the current log and memory evidence. Use final XML when available, and do not infer missing XML counts.

Relevant PRs and remote refs

This lane published no artifact and deployed no code. Existing production versions were not inspected as part of this Clock callback lane.

Next steps

1. Re-verify current state first. Clone the PR into a fresh lane, inspect its current head, and read README.md plus the linked testing guidance.
2. Read the detailed findings and XML at https://github.com/CodexCoder21Organization/UrlProtocol/blob/wip/laneC23-validation-records/rC23-findings.md . Preserve the existing targeted counts; do not add validation rounds unless source or selected test bytes changed.
3. Acquire an available complete-suite slot by checking ps and /proc working directories. Run bash scripts/test.bash --local --test . --log <lane-output.xml> once from the current head. Keep the local runner tracked and bounded, and record per-JVM memory if the process ends with exit 137.
4. Classify every sibling attempt-history element in the XML. Do not interpret a final positive as a first-attempt positive when a history exists.
5. Add the actual suite result to the Review round 7 section while retaining the opening explanation and final footer. Do not merge or request checks.

Operational details

Targeted commands, gate-names.json, all XML, history classifications, summary JSON, compressed suite log, and the memory recorder are in the evidence branch. The historical red controls are intentional; do not treat their expected negative counts as current product errors. The source checkpoint includes all nine intended round-7 files, with no generated artifacts committed. No background process from this lane remains at handoff time; see the final findings audit.