ci(test): authenticate HF model pulls in Linux CLI integration to stop 429 flakes

[kovtcharov-amd]

The Linux "Full Integration" CI job has been flaking on every release/PR — including the v0.20.0 release PR (#1334) and #1377. Root cause: it pulls Qwen3-0.6B-GGUF from HuggingFace unauthenticated, so shared GitHub runners hit 429 Too Many Requests, Lemonade fails to start, and the whole job (summarizer/RAG/lemonade-client integration) fails. The Windows CLI, SD, and Agent SDK jobs already pass HF_TOKEN and never flake — this just brings the Linux job to parity.

After this, the Linux integration job authenticates its model pulls and stops 429-flaking.

Test plan

• CI on this PR: GAIA CLI Tests (Linux) → Test GAIA CLI on Linux (Full Integration) reaches the model pull without a 429 and passes
• Confirm no secret leakage in logs (GitHub masks secrets.* automatically)

[github-actions]

Summary

Clean, well-scoped CI fix that brings the Linux integration job to parity with Windows. The change adds HUGGINGFACE_ACCESS_TOKEN / HF_TOKEN to the one step that pulls models from HuggingFace, mirroring the existing pattern in test_gaia_cli_windows.yml:76-77 exactly. The diagnosis (unauthenticated pulls → 429 on shared runners → Lemonade fails to start) is plausible and well-documented, and the inline comment captures the why in two lines without rotting. Most importantly, both model-pull operations are covered: the env block is on the Start Lemonade Server and Test Core Commands step (lines 79–228), which contains both the background lemonade-server-dev run (line 93) and the explicit lemonade-server-dev pull (line 140) — nothing is left unauthenticated.

Issues Found

None blocking.

🟢 Minor — later steps reuse the model but not the token (informational) Subsequent steps like Test evaluation and utility commands (line 230) operate against the already-running server and the model pulled in the prior step, so they don't need the token. Worth keeping in mind only if a future step adds a new model pull — it would need its own env block (or the token promoted to a job-level env:). No action needed for this PR.

Strengths

• Exact pattern parity with the Windows job (test_gaia_cli_windows.yml:76-77) rather than inventing a new approach — both HF_TOKEN and HUGGINGFACE_ACCESS_TOKEN are set since different layers of the stack read different names.
• Step-level scoping keeps the secret exposed only where it's needed, not job-wide.
• Good comment hygiene — one concise why (429 throttling on shared runners) with no narration of mechanics, matching CLAUDE.md's comment guidance.

Verdict

Approve — No blocking issues. The change is minimal, correct, covers both pull sites, and matches the established Windows pattern. Safe to merge once CI confirms the model pull reaches completion without a 429. The unchecked test-plan boxes are the right gate before merge.