fix(lemonade): don't classify generic "llama-server failed to start" as a corrupt download

[itomek]

Closes #1294

Why this matters

Before: an ordinary model-load failure (resource limits, ctx_size, GPU/backend startup, port conflicts) all surface from Lemonade as "llama-server failed to start" — and _is_corrupt_download_error treated that generic string as file corruption. On a fresh install that misread sent first-boot into a destructive delete + ~25 GB re-download that couldn't fix the real problem, then dead-ended. After: the bare failure is no longer mistaken for corruption — it surfaces as an actionable LemonadeClientError and the model cache is left intact. Genuine corruption (five specific signals) still triggers the repair flow.

Part of the fresh-install first-boot reliability set (#1293 is the stacked follow-up that fixes the non-interactive auto-heal on top of this accurate classification).

Test plan

• Unit — tests/unit/test_lemonade_error_classification.py (35 pass): bare llama-server failed to start → not corrupt (incl. the exact {code/type: model_load_error} payload from the user's boot log and an OOM variant); all five specific corruption phrases → corrupt; load_model on a bare failure raises an actionable error and calls neither delete_model nor pull_model_stream; genuine corruption still enters the repair path.
• Regression — tests/unit/test_lemonade_model_loading.py + test_lemonade_manager_preload.py (18 pass), independently re-run from a clean checkout of this branch.
• Lint — util/lint.py (black / isort / flake8 / pylint -E) clean.
• Real-world (Strix Halo — Ryzen AI MAX+ 395) — cloned branch into /tmp on AMD hardware, ran all 35 classifier tests (pass), and spot-checked live: _is_corrupt_download_error("llama-server failed to start") → False; _is_corrupt_download_error("files are incomplete") → True.

[kovtcharov-amd]

@claude review this pr.

[github-actions]

Looks correct and well-scoped — approving on the merits, with two minor non-blockers below. The fix does exactly what the issue calls for: dropping "llama-server failed to start" from the corruption phrase list so a bare load failure no longer triggers the destructive delete + ~25 GB re-download.

I traced the runtime path to confirm the behavior holds end-to-end:

• _is_corrupt_download_error now matches only the five specific phrases (src/gaia/llm/lemonade_client.py:1234).
• On a bare llama-server failed to start, load_model skips the corrupt block and falls to lemonade_client.py:2873-2881, which re-raises an actionable LemonadeClientError with the original message and never calls delete_model/pull_model_stream. ✅
• Genuine corruption still enters the resume→delete→fresh-download repair flow (lemonade_client.py:2784-2871). ✅

The test coverage is thorough — the real-world model_load_error payload, the corroboration case (startup failure + corruption phrase → still corrupt), and the load_model routing/decline cases all map cleanly onto that code path. Note: I couldn't execute the suite in this review sandbox (no pytest available), so I'm relying on your reported 35-pass run + Strix Halo spot-check for the green result.

🟢 Minor, non-blocking:

1. .claude/plans/issue-1294.md embeds personal absolute paths (/Users/tomasz/src/amd/gaia/.venv/... in test_command/lint_command). If plan artifacts are meant to live in the repo, consider scrubbing the machine-specific paths; otherwise it may be better left untracked.
2. Scope: the diff also carries black-formatting touch-ups in file_io.py / test_file_io_guardrails.py and a backup_path assertion fix in test_code_agent.py — unrelated to the title. They look like legitimate prior-commit cleanup on the branch, just worth a one-line callout in the PR body so reviewers don't wonder why they're here.

Nice surgical fix with a clear corroboration rule. The stacked #1293 follow-up for the non-interactive auto-heal is the right call to keep separate.