fix(distributed): detach cold-load staging from the request context

[localai-bot]

Problem

In distributed mode, a model not yet loaded on a worker is staged lazily on the inference request path (SmartRouter.Route → scheduleAndLoad → stageModelFiles). The staging upload is bound to the triggering request's context. Staging a multi-GB model takes minutes - far longer than any client keeps its HTTP connection open - so a browser refresh, an ingress/LB idle-timeout, or a round-robined retry landing on another frontend replica cancels the request context and aborts the upload with context canceled mid-transfer. Large models then never finish staging, so they never load.

Observed in a 2-replica deployment: both frontends repeatedly failed to stage a 15.7 GB GGUF, each attempt dying at a different offset:

ERROR File upload failed  file=...Q4_K_M.gguf size=15.7 GB offset=12409749364
      error=Put ".../...gguf": context canceled
ERROR Failed to load model modelID=... error=... staging model file: ... context canceled

(context canceled, not deadline exceeded → the caller's context was cancelled, i.e. the request was abandoned.)

Fix

Bind the cold load (staging + LoadModel + the per-model advisory lock) to context.WithoutCancel(ctx): it preserves the request's values (prefix-cache chain, etc.) but drops its cancellation/deadline. Each long step keeps its own bound - the file stager's resume budget and LoadModel's 5-minute timeout - so nothing leaks, and the per-model Postgres advisory lock still de-dupes concurrent loaders across replicas.

Test

router_staging_context_test.go reproduces the outage: the fake stager cancels the request context the moment staging begins and asserts the context the stager receives is not cancelled. Red before the fix (context canceled), green after. Full core/services/nodes suite passes; golangci-lint --new-from-merge-base=origin/master reports 0 issues.

Assisted-by: Claude:claude-opus-4-8 [Claude Code]