Make environment setup completion observable to the task and platform

[mrubens]

Problem

For environment-backed tasks, repository setup commands run in the background while the agent starts concurrently — and nothing closes the loop:

• The agent's sandbox instruction unconditionally claimed setup commands "were already executed before your task started", even while they were still installing dependencies.
• There was no observable ground truth in the sandbox: no status file, no per-command logs, nothing the agent could check or wait on.
• setupCompletedAt is stamped when the blocking portion of setup returns, i.e. before background commands actually finish, so even the DB couldn't say when setup really completed.
• The background outcome was only observed after the task ended (flush()), so a running agent never learned that setup finished or failed mid-task.

Changes

Observable ground truth in the workspace

• New EnvironmentSetupStatusWriter maintains <workspace>/.roomote/setup-status.json (atomic writes): overall state (running → completed / completed_with_warnings / failed) plus per-command state, exit code, duration, and error.
• Each command's stdout/stderr is mirrored to .roomote/setup-logs/<repo>/<command>.log; detached commands record their PM2 logfile instead.
• The full pending command plan is published before the agent can start, so a missing file never means "setup in progress".

Honest agent instructions

• buildSandboxInstruction now branches on whether background setup is still pending at instruction-build time: pending → "may still be executing, check .roomote/setup-status.json, you'll be notified when it finishes, don't re-run running commands"; settled/blocking → the previous wording plus a pointer to the recorded results.

In-session notification when setup settles

• BackgroundEnvironmentSetupController gains an onSettled notifier that fires when the background promise actually settles (not at flush time). runTask registers a listener that injects an outcome-specific message into the harness session (visibleInTranscript: false, source: 'environment-setup') — only while the task phase is running, so an idle or settled-early task is never woken. Delivery is recorded as a task-run decision event.

Truthful lifecycle in the DB (powers future UI)

• New task_runs.environment_setup_state / environment_setup_completed_at columns (migration 0010), written via a new run-scoped taskRuns.updateEnvironmentSetup mutation: running right after setup returns when background work remains, terminal state when it settles. An IS NULL guard prevents a replay from regressing a terminal state back to running.
• Each repository command emits a durable phase task-run event (environmentRepositoryCommand: <repo> <name>) through the existing phase pipeline.

setupCompletedAt semantics are unchanged (blocking-setup milestone).

Follow-up (not in this PR)

Web UI: split the Preparing startup step into per-command progress and add an interactive-phase "environment setup running / complete" indicator driven by the new taskRuns fields and phase events.

Testing

• 11 new tests: EnvironmentSetupStatusWriter lifecycle, BackgroundEnvironmentSetupController settle/notify/persist paths (including rejection), sandbox-instruction wording for pending vs. settled background setup, and execute-task-run assertions that the notifier is passed to the runtime and running → completed_with_warnings states are persisted.
• All affected worker tests pass (47), plus typecheck (types, db, sdk, worker, api, web) and lint.

[roomote-roomote]

No code issues found. See task

• apps/worker/src/commands/setup.ts:445 Background Docker setup warnings are awaited and discarded before repository-command status is finalized, allowing .roomote/setup-status.json to report completed despite an environment setup failure.
• apps/worker/src/commands/setup/workspace/setup-status.ts:58 The literal NUL in commandKey makes this TypeScript source blob binary to Git, so GitHub cannot render or review its diff.
• apps/worker/src/run-task/run-task.ts:1121 Setup can settle after the pending-state instruction is generated but before startNewTask() begins; the immediate late-listener path then drops the promised completion update because the harness is not yet running, leaving the agent with stale setup guidance.
• apps/worker/src/commands/setup.ts:404 Environments with Docker projects but no repository commands never create setup-status.json, although their background setup still causes the sandbox instruction and completion message to point the agent at that file. Initialize and finalize the status writer for Docker-only background setup too, or stop advertising it in that case.
• apps/worker/src/commands/setup/workspace/setup-status.ts:104 Duplicate command names are valid in the environment schema, but the (repository, name) map drops later commands. Their start/result callbacks overwrite the first entry, so the published plan and final status omit commands and can report the wrong lifecycle; use a per-command identity such as the command index.

_{Reviewed 418fce2}

[mrubens]

Addressed review feedback in de6322f:

• NUL byte in commandKey (setup-status.ts): replaced the literal NUL with the \u0000 escape sequence — the file is plain text again and the PR diff now renders (git diff --numstat shows 279/0 instead of binary).
• Discarded Docker warnings (setup.ts): the background path now captures backgroundDockerProjectsTask's warnings and folds them into .roomote/setup-status.json via a new addWarnings method, so the file finalizes as completed_with_warnings instead of a clean completed when Docker project setup failed. Covered by a new test.
• Settle-before-start race (run-task.ts): already fixed in 19f28ad — the settled outcome is buffered and only delivered after the runtime emits taskStarted, so a fast-settling setup can neither race the initial prompt nor be dropped.

[mrubens]

Addressed in fdc2131: .roomote/setup-status.json is now created for every environment workspace — including Docker-only and command-less setups — and executeOrganizationEnvironmentRepositoryCommands finalizes it even when it has nothing to run (including the missing-repoPaths early return, so a reader can never observe running forever). The file's existence is now an invariant everything that advertises it (sandbox instruction, settle notification) can rely on; Docker project warnings land in its warnings array via the existing addWarnings path.

[mrubens]

Addressed in 418fce2: the (repository, name) index now maps to every matching entry in plan order instead of dropping duplicates. Since repository commands execute sequentially, markCommandRunning/markCommandResult target the earliest entry still in the expected state (pending → running → terminal), so each duplicate gets its own lifecycle. Duplicate commands' log files get an occurrence suffix (install-deps.log, install-deps-2.log) so they no longer overwrite each other. Covered by a new test exercising two same-named commands with different outcomes.