fix(pixel): isolate model receipts and preserve managed marker on switches

[Lightheartdevs]

Problem

On the exact public-beta base 4fa6ad17059a2ff7df1dd92105b87ed84b801e70, Tower3 installed and passed Pixel, Hermes, UI, capabilities, and lifecycle checks, but the Dashboard's selected-model load returned 502. The owner controller returned 409 invalid-model-completion: bootstrap promotion and browser model switching had written incompatible schemas to the same completion receipt.

The next installed Tower3 run exposed a second problem. Six browser model-switch cycles and the inner release gates passed, but product uninstall refused to remove Pixel because the managed marker still described the pre-switch OpenClaw configuration. That is a real lifecycle failure, not a green host result.

Fix

• Separate bootstrap-promotion and model-switch completion receipts, while validating both legacy formats without confusing one transaction for the other.
• Before switching, validate the managed marker against the installed OpenClaw configuration. On completion or rollback, atomically bind the marker to the verified final configuration before releasing the transition. Fail closed on marker tampering, preserve idempotent replay, and support an in-flight older journal only when its prior state proves the binding.
• Include the new bounded state files in Pixel uninstall cleanup.
• Add regression tests for promotion-then-switch, six successive switches, marker binding/rollback/tampering, legacy journal replay, and uninstall cleanup.

Verification and remaining qualification

• Exact-head (afe7408) Linux source tests: model/access suite 145 passed, 1 skipped, 44 subtests; related Pixel relay/edge/Dashboard suite 155 passed, 55 subtests; test-pixel-uninstall.sh 106 passed, 0 failed; test-pixel-host-install.sh 294 passed, 0 failed. The relay/edge suite emits existing aiohttp warnings but exits cleanly.
• Exact first-commit Tower3 installed run: inner release gates passed, including Pixel and 6/6 browser model-switch cycles; outer qualification failed at uninstall because of the marker drift. This is the observed reason for the second commit, not proof the new commit fixes the installed host.
• The new coordinator prevents marker drift on future switches; it does not automatically repair an installation whose marker was already stale on an older beta commit. Tower3's preserved r207 test install was guardedly rebound to the root-verified completed model transaction and product-uninstalled successfully; its protected Qwen worker and pre-existing home backup were restored. Existing-install upgrade/uninstall migration remains a separate release question.
• Exact new-head (afe7408) Tower1 installed qualification passed bootstrap, install, product, Pixel, agentic Pixel tools, capabilities, lifecycle, and browser model-switch cycles 1–5. Cycle 6 failed only the Perplexica functional reply on Granite 3.2 2B: the app returned an apology instead of the verification phrase, while Pixel, OpenCode, LiteLLM, Open WebUI, and Hermes Talk probes passed on that switched model. The model UI runner recovered the failure, product teardown passed, and the protected Qwen worker was restored. This is a red release gate pending classification, not a claim that this PR caused or fixes the Perplexica result.
• Exact new-head Tower3 installed qualification is now User Green: fresh install, Pixel status/access/live and retained SSE, agentic Pixel tools, capabilities, lifecycle, 6/6 browser model-switch cycles, product uninstall, and protected Qwen restoration all passed. The run completed 2026-09-17T02:43:34Z with chain rc=0, model-ui summary ok=true, teardown clean=true, and workload poststate restored=true/healthVerified=true. Tower1 remains red on Granite 3.2 2B Perplexica despite its other gates and cleanup passing. Tower2, Strixy, and the Windows laptop still require full exact-new-head installed qualification; the distro lab is running and the two WSL targets are queued behind its host lock. No merge claim or fleet-green claim is made here.

The acceptance gate is clean end-to-end installed behavior, including Pixel, model switching, lifecycle/uninstall, and protected-workload restoration on every target. Source tests and CI are supporting evidence, not substitutes for that gate.