fix(preview): keep in-progress preview off after the user disables it

[joshistoast]

Summary

Turning off Show in-progress diffusion in Preview did not survive the next Invoke if the user clicked anything in the Gallery in between.

A deliberate Gallery selection (or compare/multi-select) pauses live-follow: it switches the preview off and stamps a pause time, and the next submission resumes it. An explicit toggle clears that pause, but a later selection stamped a new one, so Invoke treated the user's opt-out as a selection pause and switched the preview back on.

Now a selection records a pause only when live-follow is on or already paused. With the preview explicitly off, a selection updates the Gallery and nothing else.

• Before: toggle off → select a Gallery image → Invoke → preview turns back on.
• After: the preview stays off until the user turns it on.

The selection pause itself is unchanged: if the user never turned the preview off, selecting an image still pauses it, and the next Invoke still resumes it.

Related Issues / Discussions

Closes #9795

QA Instructions

• pnpm check:release (webv2) passed: lint/types/architecture, unit (10177), browser (2895), architecture performance, project-file journeys, accessibility.
• New reducer test keeps an explicit live-follow opt-out through later Gallery selections and submissions covers select + compare followed by submit. It fails on main and passes here.
• Browser (mock backend; socket handshake and enqueue_batch stubbed): turn off the hourglass toggle in Preview, select a Gallery item, press Invoke.
  • main: the toggle flips back to "Hide in-progress diffusion" (pressed).
  • This branch: it stays "Show in-progress diffusion" (not pressed).

Review

No material findings. Limitations:

• A project saved with the old bug's stale pause resumes the preview once more, on its next Invoke. The next explicit toggle clears that pause.
• A selection pause and an explicit opt-out look the same in the toolbar (toggle off). Only the explicit opt-out now persists through Invoke.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Meaningful regression coverage added / updated where needed; obsolete tests/code removed
• Persisted-state and API changes include required migrations / compatibility validation
• Relevant performance/efficiency opportunities considered; material claims have evidence
• Material review findings resolved and relevant checks rerun
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[lstein]

Reviewed at 6ddd25a. No blockers; approving.

The opt-out/pause distinction (showProgressImagesInViewer off with vs. without liveFollowPausedAt) holds across every writer of that state: the pause helper (now skips the stamp on an explicit opt-out), the submit snapshot builder (the sole queue-item creation site; resumes only with a stamp), and setActiveProjectSettings (the hourglass toggle, tile follow() and the settings dialog all route through updateProjectPreferences, which clears the stamp). I found no path that drops the stamp (project serialization, session-scoped gallery stripping, layout preset switches, and every gallery-values replacement keep it), so a selection pause can't silently degrade into a permanent opt-out. Results arriving while opted out still can't take the selection, since shouldSelectGalleryResult requires live-follow on.

Checks: workbenchState.test.ts passes (327), lint:tsc clean, and the new test fails against the base reducer.

Non-blocking:

1. The && getLiveFollowPausedAt(project) === null half of the guard survives mutation: removing it leaves all 6293 workbench tests green. It's also behaviorally equivalent today, because every submit resumes live-follow, so no queue item can be submitted between an older pause stamp and a re-stamp. Fine to keep as a safeguard, but a short comment or test would stop it being removed as dead code.
2. Projects already saved with the old bug's stale stamp resume once more, as the PR notes. An old stamp can't be told apart from a real selection pause, so I don't see a better fix.
3. The new test stops at submit and doesn't cover results routing. That logic is unchanged, so this is minor.