fix(llama-cpp): cap single-pass embedding batch to fit VRAM

[localai-bot]

Symptom

Embedding models with a large context window crash on load — the backend process
aborts (exitCode=-1) — even with plenty of free VRAM. Reproduced live with
qwen3-embedding-4b (context=40960 → n_batch=40960 → abort) and
qwen3-embedding-0.6b (n_batch=8192). Pinning batch: 512 avoids it. The
failure is VRAM-independent: the batch was sized with no awareness of the device.

Root cause

For single-pass usecases (FLAG_EMBEDDINGS / FLAG_SCORE / FLAG_RERANK),
core/backend.EffectiveBatchSize returned the full EffectiveContextSize as the
physical batch (n_batch / n_ubatch) with no upper bound and no VRAM awareness.
The CUDA compute buffer scales ~ n_ubatch * n_ctx and is allocated per device
(it can't be split across GPUs), so a full ctx-sized n_ubatch turns into multi-GiB
of scratch that must fit on a single card and aborts the load.

This is the same root cause as #10485 ("a large context turns the batch into
multi-GiB of extra scratch that must fit on a SINGLE card"), for which the config
layer already grew a VRAM headroom guard (PhysicalBatchForContext,
largeContextForDevice, computeBufferBytesPerCell, blackwellBatchHeadroomDivisor).
But that guard only gated the Blackwell 512→2048 batch boost — the single-pass
embedding path bypassed it entirely (EffectiveBatchSize didn't even take a GPU).

Fix

Make the single-pass batch VRAM-aware. New config.SinglePassBatchForContext(gpu, ctx)
returns the largest batch whose compute buffer fits the per-device VRAM headroom
(VRAM / blackwellBatchHeadroomDivisor), clamped to [DefaultPhysicalBatch, ctx],
reusing the existing computeBufferBytesPerCell / headroom-divisor math (no
duplication). EffectiveBatchSize calls it for the single-pass path:

• Explicit c.Batch != 0 still short-circuits and wins.
• Single-pass with ctx > DefaultBatchSize → SinglePassBatchForContext(localGPU(), ctx).
• Unknown per-device VRAM (0) stays conservative (returns DefaultPhysicalBatch,
  not the unbounded context) so a detection gap can't OOM the load.

The GPU is threaded in via an injectable package var (var localGPU = config.LocalGPU,
mirroring the existing localGPU seam in hardware_defaults.go). config.LocalGPU
wraps the sync.Once-cached xsysinfo detection, so the per-request call from the
router's prompt trimmer (modelTokenTrim) stays cheap. The exported
EffectiveBatchSize signature is unchanged, so both callers (grpcModelOpts and
route_model.go) need no edits.

The original single-pass intent is documented in a WHY comment: single-pass wants
batch >= input so pooling is one pass and avoids GGML_ASSERT(n_tokens <= n_batch)
and the "input is too large to process" error. The cap is "the largest batch that
fits VRAM"; an input longer than the cap is the accepted tradeoff — a batch that OOMs
the device processes nothing at all.

Test coverage (Ginkgo v2 + Gomega)

• core/backend/options_internal_test.go — new EffectiveBatchSize VRAM cap
  Describe: large embedding context (40960) on a small 20 GiB device → bounded batch
  < context and >= DefaultBatchSize; explicit batch: wins; unknown VRAM (0) →
  conservative (DefaultBatchSize, not context); non-single-pass → DefaultBatchSize.
  The existing grpcModelOpts NBatch cases now inject a deterministic high-VRAM GPU
  (they became VRAM-dependent).
• core/config/hardware_defaults_internal_test.go — new SinglePassBatchForContext
  Describe: default when ctx ≤ default; full context when the buffer fits ample VRAM;
  caps below context when a large context overflows the headroom (with an explicit
  buffer-fits-headroom assertion); floors at DefaultPhysicalBatch on tight VRAM;
  conservative default when VRAM is unknown.

The GPU is injected via the package-var pattern; no stdlib testing assertions.

Verification

• go build ./core/backend/... ./core/config/... — passes.
• go test ./core/backend/... ./core/config/... — passes (new specs verified running).
• golangci-lint run ./core/backend/ ./core/config/ (and make lint new-from-master) — 0 issues.

Notes

• The local pre-commit coverage gate (make test-coverage-check) was skipped at the
  maintainer's request; CI runs the full lint + coverage suite.
• Per the repo's AI-assist policy, this commit carries an Assisted-by: trailer and
  intentionally has no Signed-off-by — a maintainer must add their own
  Signed-off-by to certify DCO.