loader: diagnose a missing core tensor instead of just naming it (#586)

[ZacharyZcR]

Picks up the gap you identified at the end of #586:

we think the error message itself is the real gap here — "missing model.norm.weight" gives you no way to know the container is just incomplete. We're looking at making the engine say that explicitly (how many shards/tensors it found, which core ones are missing, "looks like an incomplete download").

That thread took three rounds to reach the answer, and the reasoning that got there is mechanical enough for the engine to do itself: the final norm and lm_head are written into the last shards, so a truncated transfer indexes nearly every tensor and then dies on the first one from the gap.

What it prints now

out-NNNNN converter layout, truncated tail — @xbais's exact situation (125 files, out-00000..out-00121):

missing model.norm.weight

  indexed 4821 tensors from 125 shard file(s)
  shards numbered 00000..00121, 122 file(s) (contiguous: a gap would be at the tail)

  'model.norm.weight' is written into one of the LAST shards, so a container whose tail
  never arrived indexes almost everything and then fails exactly here.
  An incomplete transfer is far more likely than a corrupt engine. Re-running the
  download resumes only the missing shards; the HF xet backend is known to stall
  mid-transfer (#452), so disable it:
      HF_HUB_DISABLE_XET=1 hf download <repo> --local-dir <model-dir>
  If your shard count is already complete, that IS a bug worth reporting.

HF layout, where -of-NNNNN gives an authoritative total, so the gap is stated as a fact rather than an inference:

  indexed 4500 tensors from 122 shard file(s)
  shard filenames declare 144 shards, but only 122 are here -- 22 MISSING

The conclusion follows the evidence. With every declared shard present, advising a re-download would send the user round a loop that cannot help, so it flips:

  shard filenames declare 144 shards and 144 are here

  'model.norm.weight' is a core tensor the engine cannot run without, and every shard the
  filenames declare is present -- so this is NOT the usual truncated download.
  Either the container was built without this tensor, or the engine is looking
  for the wrong name. Please report it with this output.

Zero indexed tensors is a different failure wearing the same message, and is reported as one:

  No safetensors tensors were indexed at all. --model must point AT the
  container directory -- the one holding the *.safetensors shards.

Gaps in the middle print (GAPS in the numbering) rather than the tail inference, and a non-tail tensor name drops the "LAST shards" sentence, which would be false for an expert weight.

Scope

st_die_missing() in st.h, wired into ld() and the fatal branch of the expert-tensor load. The non-fatal probe branch at colibri.c:1488 keeps its one-line missing log on purpose — it runs per expert and must not flood. No loading behaviour changes; this only replaces fprintf + exit(1) on paths that were already fatal.

Verification

make -C c colibri ARCH=x86-64-v3 clean, make check 197 passed / 13 skipped.

The five reporting branches were exercised directly, by building a throwaway harness that includes st.h and hand-populates a shards struct (paths/n/nfd) for each layout — truncated out-* tail, HF -of- gap, complete HF container, mid-numbering hole with an expert tensor name, and zero tensors. The outputs above are that harness's real output, not hand-written samples. The harness is not part of this PR since it would need a Makefile target of its own; happy to add it as a proper test if you'd rather have the branches locked down in CI.

Not reproduced against a genuinely truncated 372 GB container — I don't have one — so the shard-arithmetic is verified against synthesised layouts, not a real interrupted download.