Website modifications

The Changes tab's whole read, in one call.

``publishable`` answers the only question the tab's button needs: there is a change awaiting approval, it belongs to this console thread, and both the run id and the approval bundle ref needed to approve it are known.

Drive the run to completion, THEN clear pending, close the PR, unlock.

Order is the fix for a live bug: cleanup-first left the parked Temporal workflow squatting on the thread's workflow id whenever the reject could not be delivered (a change discarded mid-planning has no approval bundle to reject), and the next submit — with every sor gate now green — hit the engine's raw TEMPORAL_START_FAILED. The unwind now runs FIRST and fails LOUDLY: on failure nothing has been cleared, the pending change is still visible, and the cancel can simply be retried. Only once a completion lever is armed (reject delivered, workflow already gone, or the run tombstoned so the plan surface terminates it) does the local cleanup run — idempotent with the engine's own reject-path cleanup.

202: the request is recorded on the thread and a run is started on it.

The run then drives the unchanged pipeline — plan-and-open-pr, preview polling, the approval gate this tab's Publish answers, merge-deploy — so the console never has to reimplement any stage of it. Poll the GET for the pending change and the preview URL.

``text`` still rides along as the run's ``user_message`` input (the workflow reads it); it is ALSO written to the thread, because an input is not a record — before that, a reload lost the operator's own words.

Keystone staff only: the reason and what the check had found are kept in ``website_check_overrides``. 409 when nothing is held back.

202: the session pod looks again, without the site agent, at the pages a check that never reached the browser was to look at. The state read shows ``rechecking`` until the new check lands. 409 for a check a look cannot settle (problems the agent saw), or while the agent works.

202: the answer is on the thread and the parked run resumes with it.

Continue lets the agent carry out the plan it described; Stop reverts the work so far. Either way the change goes back to ``planning`` until the agent reports again.

The owner's "no" to rebuilding a Publish the site's own, direct changes refused: the change is let go for good, and the editor stops calling it a failure (dev 2026-10-02: "no" did nothing, and the question came back).

Nothing is left to clean: the engine retired the change at the refused merge (PR closed, pending cleared, lock released), and this read's own retire catches any leftover. 409 when the thread's failed run noted no such conflict.

Poll Redis progress for the in-flight plan and emit SSE until terminal.

202: the approval is recorded and the engine merges to main and deploys.

Publish IS the approval — one action, no separate approve step. It is delivered as the control plane's approval decision rather than a direct ``merge_and_deploy`` because the run is parked on that approval signal: a console-side merge would leave the workflow waiting forever on a PR that no longer exists, and the deploy-completion signal it later receives would never be read.

Idempotent: a request no longer queued answers ``removed: false``. 409 ``QUEUE_ITEM_SENDING`` for one already on its way.

What the agent did for each recent request — read back after a page reload so the folded "What the agent did" account stays under the message that asked for it. Two weeks of history, oldest first.

The console calls this every minute or so while the site editor is open. A slot whose lease nobody extends lapses (the pool's LEASE_TTL) and the pod goes back to the warm floor — so tabs are viewers, and closing the last one is what frees the slot, never a client-side beforeunload. 404 for a website not in session mode; a website holding no lease gets the plain "enabled, nothing serving" response (pre-warm is what claims).

Called by the console when the operator opens the site editor, so the pod has cloned, installed and booted `next dev` before the first change request arrives — the whole point of pre-warming. Idempotent: a pod already serving this site at the right commit is left alone.

404 for a website not in session mode, so the console can fire this unconditionally and simply learn that the pilot does not apply here.

The owner's Stop: the site agent's turn ends at its next step, and what it changed so far becomes the change to review — publish it, ask for more, or discard it. (Discard is the stop that throws the work away.) 409 when this thread has no change being made, or its run cannot be reached, or the run the Stop names (``plan_request_id``) is not the one being made: a Stop that arrives late must not stop the queued request that followed.

The owner's Undo: the change in review goes back to the version before its newest (the branch, the preview, the summary), and the next request builds on that. Only the newest version, while this thread's change waits for review and is not being published; with the version that opened the change left, Discard is the way. What it changed in the business records stays.