fix(cookbook): recover completed downloads from DOWNLOAD_OK in background reconciler

[maxmilian]

Summary

A completed model download was being shown as crashed on the dashboard. The background status reconciler (static/js/cookbookRunning.js, _pollBackgroundStatus) only recovered done for dependency installs when the backend reported a finished task as stopped. A real model download whose tmux pane is gone after DOWNLOAD_OK (so the dead-session check misses the landed snapshot) fell through to task.type === 'download' ? 'crashed', so a download you watched reach DOWNLOAD OK showed up as crashed after navigating away (and stalled on the Serve tab). This mirrors the existing dep-install recovery into the download branch.

Target branch

• This PR targets dev, not main.

Linked Issue

Fixes #3897

Type of Change

• Bug fix (non-breaking — fixes a confirmed issue)

Checklist

• I searched open issues and open PRs — this is not a duplicate.
• This PR targets dev
• My changes are limited to the scope described above — no unrelated refactors or whitespace changes mixed in.
• I actually ran the app (uvicorn app:app) and verified the change end-to-end — see the before/after below.

How to Test

1. Open Cookbook, download a model and wait for DOWNLOAD OK.
2. Navigate away (e.g. to the Serve tab) so the download's tmux pane is reaped and the next /api/cookbook/tasks/status poll reports the task as stopped.
3. Return to the Download/Running tab.
   • Before: the finished model is shown as crashed (and stalled on Serve).
   • After: because the retained output still carries DOWNLOAD_OK, the reconciler recovers it to finished/done instead of crashed.

Regression test (source-invariant pin, same style as the existing dep-install test — this repo has no JS test runner):

python -m pytest tests/test_cookbook_dependency_completion_regression.py

node --check static/js/cookbookRunning.js passes.

Root cause

_pollBackgroundStatus(): on live.status === 'stopped', only depDone (payload._dep + _depInstallSucceeded) recovered done; a model download had no equivalent recovery, so task.type === 'download' mapped straight to crashed.

Fix

Add downloadDone = task.type === 'download' && String(task.output || '').includes('DOWNLOAD_OK') and treat depDone || downloadDone as recovered. DOWNLOAD_OK is emitted by the runner only after it exits 0 (if [ $_ec -eq 0 ]; then echo "DOWNLOAD_OK"), so it's a conclusive terminal marker.

This background poll keys off DOWNLOAD_OK only — deliberately not the /snapshots/ path that the reconnect loop also accepts. The reconnect loop runs with the live stream in view and can debounce ambiguous markers; this poll runs blind after a refresh, and /snapshots/ can be printed mid-stream for multi-file downloads, so accepting it here could mark an incomplete download done. Keying off the exit-0 sentinel keeps the blind path conservative.

Visual / UI changes

This is a status-computation change inside a static/js/ module, not a styling change: a finished download resolves to the existing done/finished badge instead of the crashed one — no new colors, classes, fonts, spacing, SVG, or component patterns, and the same rendering path is reused.

Verified end-to-end against a locally-run app (uvicorn app:app): a download task whose output carries DOWNLOAD_OK is driven into the dead-session (stopped) state that the /api/cookbook/tasks/status poll reports, then the Running tab is rendered.

Before (current dev) — the completed download is mislabeled crashed:

After (this PR) — the same task recovers to finished:

• Screenshot of the change in the running app (before/after above).
• Style match: reuses the existing finished/done badge + green check; no new colors/classes/fonts/spacing/SVG.
• No new component patterns — the existing card rendering path is reused.
• Not a bulk auto-generated PR — single focused fix; root cause filed and claimed on download marking as crashed #3897 first.

Scope

Deliberately does not touch the backend status detection. If the backend separately reports stopped for GGUF cache layouts where it should report completed, that's a distinct follow-up; this PR fixes the frontend mislabel of a download that already emitted DOWNLOAD_OK.

[pewdiepie-archdaemon]

This still covers a frontend reconciliation edge after the backend dead-download classifier work: if the background status poll sees a stopped download whose retained output has DOWNLOAD_OK, the local task should recover to done instead of crashed. I temporarily merged current origin/dev locally and verified the combined result: node --check static/js/cookbookRunning.js, git diff --check origin/dev...HEAD, and /home/diogenes/selfhost/odysseus-ui/venv/bin/python -m pytest tests/test_cookbook_dependency_completion_regression.py tests/test_cookbook_dead_download_status.py -> 20 passed.