fix(model-artifacts): persist companion artifacts so remote workers get the base_model option

[localai-bot]

The bug

Distributed loads of a model with a companion artifact (e.g. longcat-video-avatar-1.5, whose base_model companion points at meituan-longcat/LongCat-Video) fail on the remote worker with:

rpc error: code = InvalidArgument desc = base_model must point to a LongCat-Video checkpoint

and the backend log shows it fetching the base repo itself instead of using the staged companion:

Downloading required files for meituan-longcat/LongCat-Video

Root cause

preloadOne resolves the full artifact set (primary + every companion) in memory, but the binding written back to disk carried only the primary:

// persistArtifactBinding, before
encoded, err := yaml.Marshal([]modelartifacts.Spec{result.Spec})
...
setMappingValue(target, "artifacts", ...)   // replaces the WHOLE artifacts: list

setMappingValue overwrites the entire artifacts: list, so every target: companion entry was silently dropped from the config file.

In a single process this is invisible (the in-memory config still holds the companion). It bites on the next controller restart: the config reloads from the mangled file with the primary alone, so withCompanionArtifactOptions finds no resolved companion and synthesizes no base_model option. The remote longcat-video backend never receives base_model, falls back to BASE_MODEL_ID, and downloads the repo itself — failing validation.

This also explains the discriminating observation from live testing: adding an explicit base_model:<path> to the model's options: works, while the managed companion does not. Explicit options live in options:, which the binding never rewrites; the managed companion lives in artifacts:, which the binding overwrote.

What this is NOT

The companion path nesting (bare /models/.artifacts/... vs per-model staged /models/longcat-video-avatar-1.5/.artifacts/...) is already handled by #10949: staging derives the worker ModelPath as the nested per-model staged root, and the relative companion option resolves under it (router_companionstage_test.go pins this). Rewriting the option with a per-model prefix would double the nesting and break it, so staging is left untouched. Once the option is generated again (this fix), the existing staging/resolution path works.

The fix

• persistArtifactBinding now writes the full resolved artifact set (primary + all companions).
• bindingNeedsPersistence compares the whole artifact list, so a companion resolving for the first time still triggers a write.

Single-node is unaffected (the in-memory config already carried the companion). The gallery-install path (bindPrimaryArtifact) already persisted the full list; only the preload write-back was lossy.

Tests (TDD, Ginkgo/Gomega)

• New failing-first spec keeps every resolved artifact in the persisted file across a reload (models a controller restart with a fresh loader): red before, green after.
• New persistArtifactBinding unit spec proving both primary and companion survive the write.

Verification (exit codes read separately)

• go build ./core/... ./pkg/... → 0
• go test ./core/backend/ → 0
• go test ./core/services/nodes/ → 0 (196s)
• go test ./core/config/ → 0
• golangci-lint run --new-from-merge-base=origin/master ./core/config/ → 0

This is the last blocker in the distributed video-model bring-up (after #10986, #11029, #11030, #11053, #11071): the backend now receives the managed base_model companion and resolves it from the staged snapshot instead of downloading it.

🤖 Generated with Claude Code

https://claude.ai/code/session_0156CbKpDh8qbAYzJZJDZ2yk