fix: preserve workspace finalization during watchdog recovery (#16247)

Keep task completion separate from runtime and workspace settlement. Permit verified board file-only repair of successful legacy retained-source runs without authorizing replay.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

doc/execution-semantics.md

@@ -1025,6 +1025,14 @@ In the normal non-terminal case, critical silence remains a UI signal and does n
 
 Source-resolved watchdog folding concerns stale active-run bookkeeping after a valid terminal disposition. It does not infer productivity from run counts, comment frequency, or elapsed task time.
 
+Terminal task activity does not prove that the execution runtime has finished.
+The scan leaves native runs with their native lifecycle owner. An active managed
+environment lease, running or failed workspace finalization, or recorded
+copy-back failure also prevents folding. These obligations are checked before
+local process cleanup and again when the run is committed. The owning runtime
+or its bounded recovery saves the files and settles the run; the watchdog does
+not replace that work with a successful result or release its execution locks.
+
 Detached process cleanup is operational hygiene, not source issue liveness. Cleanup should be best-effort and auditable. If cleanup fails but the source issue is already terminal with same-run durable evidence, Paperclip should preserve the cleanup failure on the run/watchdog audit trail and route only the cleanup concern to bounded recovery when a real owner/action remains.
 
 ## 13. Auto-Recover vs Explicit Recovery vs Human Escalation

doc/workspace-restore-locks.md

@@ -90,10 +90,18 @@ Only a board operator can record this repair. It preserves the current task
 owner, conversation generation, status, and execution locks. It does not queue a
 continuation or replay the stopped run; after repair, any new work still follows
 the normal admission rules.
-The board currently shows repair guidance and an Inspect run link, not a repair
-form. Recording the decision is an operator API/runbook workflow; the recovery
-API response contains the exact action and lease IDs. Provider access may require
-an instance administrator or Cloud support. This change does not add a repair UI.
+The original legacy run may be `succeeded` while required files still need
+repair. Verified file-only repair accepts that terminal result and keeps it
+unchanged. It still requires the retained-source record, exact remote stop
+receipts, and recovered-file evidence. A successful result does not permit a
+normal execution retry, and a queued or running source cannot be repaired this
+way. Later saved messages can continue through ordinary admission after the
+file hold clears.
+The board shows repair guidance, an Inspect run link, and a Record file recovery
+form for operators with runtime access. The form requires recovered-file evidence
+and confirmation; the API verifies the original stop receipts. The operator API
+also supports this workflow and returns the exact action and lease IDs. Provider
+access may require an instance administrator or Cloud support.
 Then use the provider's operator console to remove that exact retained
 allocation when its files are no longer needed. Verify its immutable provider
 allocation ID against the recorded lease before removal. The ordinary reusable