Fixes #18229

Summary

When a model is loaded, the runner logs the effective num_ctx but not where it came from, so a silent deviation from the Modelfile (e.g. a client request overriding it) goes unnoticed. This adds a num_ctx_source attr to the existing load/reload/unload log lines, reporting which level of the documented precedence chain supplied the value: request → modelfile → env (OLLAMA_CONTEXT_LENGTH) → default.

Implementation

• numCtxSource(model, requestOpts) in server/routes.go — computed beside the existing usesAutomaticNumCtx in scheduleRunner, from the raw request/model maps (not the merged value), so a request that merely matches the Modelfile number still reports request.
• Threaded getRunner → LlmRequest.numCtxSource → runnerRef.numCtxSource (the same path the existing numCtxAuto bool uses) and emitted by runnerRef.LogValue() immediately after the existing num_ctx attr.
• Logging-only: no behavior change. New log shape for the issue's scenario (Modelfile 65536, request 16384):

DBG finished setting up runner=name=mymodel size=4.7GB ... num_ctx=16384 num_ctx_source=request

Known limits (deliberate): the auto-tier OOM reduction (only reachable when source is default) and the small floors can lower the effective value without changing the attr — both already have their own log signals; ollama ps display is out of scope.

Tests

server/routes_options_test.go: TestNumCtxSource covers all four sources plus the invariant usesAutomaticNumCtx == (source == "default"). go build, go vet, and the full go test ./server/ -count=1 pass; gofmt -l clean.