Refresh screenshots for v2026.529.0 and fix workspace env precedence

Recapture the 82 stale screenshots (light + dark, 1440×900 @2x) against
a release-code instance booted at v2026.529.0 (911a1e8). Registry was
already stamped at that SHA, so captured_sha is unchanged.

Verification pass against the release codebase also found one authored
claim wrong: the execution-workspace environment precedence is
issue → project → agent → instance default (project policy outranks an
agent's own default), not issue → agent → project. Corrected
docs/guides/projects-workflow/workspaces.md to match
server/src/services/execution-workspace-policy.ts.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

docs/guides/projects-workflow/workspaces.md

@@ -50,7 +50,7 @@ The task runs in the project's primary checkout, not an isolated copy. Use this
 
 Reusing a workspace is convenient, but it raises a fair question: what happens when two different agents — with two different intended environments — land in the same workspace? Paperclip closes that gap so a reused workspace never quietly drifts.
 
-- **No silent environment reuse.** Each task run has an intended environment, resolved from the issue's explicit override first, then the agent's default, then the project policy, then the instance default. When a run reuses a workspace whose environment doesn't match its intended one, Paperclip treats that as a conflict to surface rather than silently inheriting whatever the previous occupant left behind. An environment you set explicitly on an issue always wins.
+- **No silent environment reuse.** Each task run has an intended environment, resolved in this order: an environment set explicitly on the issue always wins; otherwise the project's workspace-policy environment applies; otherwise the agent's own default environment; and the instance default is the final fallback. (An agent deliberately pinned to the local default is never promoted off it by a project policy — only an explicit issue-level environment can move it.) When a run reuses a workspace whose environment doesn't match the run's intended one, Paperclip treats that as a conflict to surface rather than silently inheriting whatever the previous occupant left behind.
 - **Dependent issues wait for finalize.** When an issue depends on another, its wake no longer fires before the upstream workspace has finished finalizing. The dependent task only starts once the workspace it relies on is in a consistent, settled state — so it never reads a half-written checkout.
 - **Accepting an interaction waits too.** Accepting a plan or review (`issue.interaction.accept`) now waits for the workspace to finalize before it proceeds, for the same reason.