Follow-up from #658.\n\n## Problem\nOllama model downloads currently stream from /api/pull with an unlimited axios timeout:\n\nts\n{ responseType: 'stream', timeout: 0, signal }\n\n\nThe current implementation supports explicit cancellation with AbortSignal, which is useful. The remaining edge case is a model pull that stops making progress because the Ollama server, network path, or underlying connection becomes wedged without cleanly erroring or ending.\n\n## Why it matters\nLarge model pulls can legitimately take a long time, so a short HTTP timeout is not appropriate. But if no progress is observed for an extended period, the background worker can remain occupied indefinitely and the UI may continue to show a stuck active download.\n\n## Suggested direction\nConsider one of these approaches:\n\n- A generous hard timeout for the overall pull, such as 2-4 hours.\n- Stall detection based on progress events, such as aborting if no bytes/progress events are observed for a configurable period.\n- A combination of both, with user-facing status that distinguishes cancellation, timeout, and retryable failures.\n\n## Current area\n- admin/app/services/ollama_service.ts model pull stream handling\n- admin/app/jobs/download_model_job.ts and related download status handling may need to reflect timeout/stall states\n\n## Notes\nThis is split out from #658 as a separate design/implementation discussion. It may need maintainer guidance before a PR because model sizes and offline/slow-network expectations affect the right timeout behavior.