docs(FIX-OFFLOAD-DOCS-957): weight offload is refused at startup, not accepted and inert (#957)

[localai-bot]

docs(FIX-OFFLOAD-DOCS-957): weight offload is refused at startup, not accepted and inert

Closes #957. No code moves.

4a183b731 (#887) turned a configured weight offload from ACCEPTED-AND-INERT
into a hard startup refusal, and neither public document followed. Both still
described the behaviour that commit replaced, so a reader who followed them
would add --offload-config expecting a no-op and get a server that does not
start.

What the engine actually does

RefuseUnsupportedWeightOffload (weight_offloader.cpp:72-83) throws when
offloading is enabled and the resolved architecture does not declare support. It
is called unconditionally from the load path (model_loader.cpp:1410-1414),
right after ModelRegistry::Resolve and BEFORE any weight I/O.

ModelFactory::supports_weight_offload defaults to false and NO model in the
tree sets it, so EVERY architecture is refused today. The tree asserts this
itself: test_weight_offloader.cpp:376-379 counts the declaring models and
carries the message "a model now declares supports_weight_offload; update this".
Negative control on the grep: a misspelled needle returns 0, so the empty set is
not a wrong search term.

A second refusal from that commit was also undocumented —
VerifyWeightOffloadWasConsulted throws after load when a model declares
support and then consults the offloader about zero weights, reported as a defect
in that loader rather than a configuration error. The old refusal list covered
config validation only.

Checked, not assumed

The example error names Qwen3MoeForCausalLM, which is a real registered
architecture (qwen3_moe_registry.cpp:181). An invented name in an error
example is indistinguishable from a real one to a reader. The "only when
enabled" claim is weight_offloader.cpp:75. The quoted message is transcribed
from the throw.

docs/STATUS.md needed no change: it already lists weight offload under what is
owed and never claimed the inert behaviour.

THIS DOES NOT MAKE documentation-checkpoint GREEN

check-doc-checkpoint.py evaluates each commit against its OWN parent, so no
later commit can satisfy an earlier one, and there is no waiver mechanism
(:256 says exempting named paths was deliberately avoided). Measured:
docs/FEATURES.md/docs/USAGE.md changed in 66 commits since 73d217db, which
still reports ERROR. The 28-commit backlog is closed only by advancing the base
or changing the checker, and this row takes neither decision.

The other 27 owed nothing

Audited all 28. The 19 MODEL-MM-indextts2 commits are intermediate waves whose
campaign documented itself at f374ab8ed once the pipeline rendered end to end,
and every one is an ancestor of it. The 3 ENG-EXPERT-STREAM commits are
deliberately unwired staged slices that docs/FEATURES.md must NOT claim —
#918's own body says "Nothing wired to a loader". Four earlier
ENG-WEIGHT-OFFLOAD commits predate 62406c30e, which documented them.
fba312c67 is a record/measurement commit shipping no user surface.

A staged campaign that documents itself once, when the capability becomes
reachable, is the CORRECT shape. The gate flags every wave that is not that
commit, so a large flagged count is expected and is not by itself evidence of
stale docs. Only a commit landing user-visible behaviour AFTER its campaign's
docs can make a document wrong. Exactly one of the 28 did.

Spec: .agents/specs/offload-docs-refusal.md.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [claude-code]