fix(gguf): correct the Q8_0 / Q5_0 / Q5_1 quantization labels

[Hoang130203]

Summary

gguf_inspector._FILE_TYPE_LABELS maps a GGUF's general.file_type to a
quantization name. llama.cpp's llama_ftype enum leaves 4, 5 and 6 unused —
Q4_1_SOME_F16, Q4_2 and Q4_3 were removed — and resumes at 7. The table
closed that gap, shifting three codes down by one:

    6: "Q5_0",
    7: "Q5_1",
    8: "Q8_0",

Built synthetic GGUFs with each file_type and ran the shipped parser over
them:

 ftype  llama.cpp                  ODS reports
     4  (removed / no such ftype)  4
     5  (removed / no such ftype)  5
     6  (removed / no such ftype)  Q5_0
     7  Q8_0                       Q5_1          <-- WRONG
     8  Q5_0                       Q8_0          <-- WRONG
     9  Q5_1                       9             <-- WRONG

A Q8_0 model is displayed as Q5_1, a Q5_0 model as Q8_0, and a Q5_1
model as the bare number 9. Code 6 gets a label for a type llama.cpp never
emits.

Why this is a transcription slip and not a different convention

The rest of the table is exactly right. Checked every remaining row against the
enum:

ODS table rows 10-34 vs llama.cpp enum:
  mismatches in 10-34: none — the rest of the table matches exactly

25 consecutive rows agree; the only three that do not are precisely the ones
straddling the removed-type gap. Someone transcribed the enum and closed a hole
that was meant to stay open.

Impact

Every bundled tier ships Q4_K_M (ftype 15), which maps correctly — so this
is invisible on a default install and only surfaces for users who bring their
own Q8_0 / Q5_0 / Q5_1 GGUF. Those are exactly the people who chose a
quantization deliberately and are most likely to care that the dashboard names
it wrong. performance_oracle consumes this parser's output for fit reporting.

Fix

Move the three rows to their real codes and drop the invented 6. One-line
comment recording why the gap exists, so it does not get closed again.

AI Assistance

AI assisted with drafting the tests and wording this description. I found the
shift by running the shipped table against synthetic GGUFs for each code and
diffing the whole table against the enum — that comparison is what showed only
the three gap-adjacent rows disagree.

Release Lane

• Stable hotfix targeting release/2.6.x
• Mainline change targeting main
• Next-minor work targeting the next feature/minor release
• Not sure; reviewer should help classify

Stable hotfix reason:

n/a

Changed Surface

• Docs only
• Tests only
• Dashboard UI
• Dashboard API / host agent
• Installer / bootstrap / lifecycle
• Docker Compose / service manifests
• Model routing / Hermes / capabilities
• Network exposure / auth / proxy
• Dependencies / runtime wiring

(Three entries in a lookup table in gguf_inspector.py, and its tests.)

Risk And Validation

• Risk level: Low
• Validation run:
  • git diff --check
  • Markdown/link sanity for docs
  • Focused tests listed below
  • Dashboard lint/test/build
  • Extension audit / compose validation
  • Release-grade fleet or scoped hardware validation
  • Stable-lane patch validation, if targeting release/2.6.x

Commands/results:

$ python3 -m py_compile extensions/services/dashboard-api/gguf_inspector.py
py OK

$ python3 -m pytest tests/test_gguf_inspector.py -q
43 passed

# after the fix, same synthetic GGUFs:
  ftype  6 -> 6        ok
  ftype  7 -> Q8_0     ok
  ftype  8 -> Q5_0     ok
  ftype  9 -> Q5_1     ok
  ftype 15 -> Q4_K_M   ok
  ftype 32 -> BF16     ok

# the new assertions against origin/main's table:
FAILED test_file_type_maps_to_the_llama_cpp_label[7-Q8_0]
FAILED test_file_type_maps_to_the_llama_cpp_label[8-Q5_0]
FAILED test_file_type_maps_to_the_llama_cpp_label[9-Q5_1]
FAILED test_removed_file_types_have_no_label[6]
4 failed, 39 passed

Caveat — what I verified and what I am citing. I proved the behaviour
above by running the parser over GGUFs I built byte by byte, and I proved the
internal inconsistency by diffing the whole table against the enum. What I did
not do is read a real Q8_0 GGUF produced by llama-quantize, because I have no
such file here and no network access to fetch one. The claim that 7/8/9 are
Q8_0/Q5_0/Q5_1 comes from llama.cpp's llama_ftype in llama.h. If you have a
Q8_0 GGUF handy, python3 -c "import gguf_inspector; print(gguf_inspector.inspect_gguf('...')['quantization'])"
settles it in one command — worth doing before merge, since I am asserting an
external constant.

Operational Change Check

inspect_gguf() is a read-only metadata parser behind model fit/performance
reporting. The change alters three entries in a display-label lookup. It reads
no more of the file, changes no parsing logic, and nothing branches on the
label — performance_oracle consumes the numeric fields. The visible effect is
that three quantization names are now the ones llama.cpp uses.

• This is not an operational change.
• This is an operational change and validation is recorded above.
• This is an operational change and validation is intentionally deferred for:

Notes For Reviewers

Codes 4, 5 and 6 now report the raw integer, which is what the existing
test_unknown_file_type_falls_back_to_stringified_int behaviour already does
for anything unmapped. That is the honest answer for a type llama.cpp cannot
produce. If you would rather they say something like "removed", that is a
one-line change — but I would keep them unmapped so a future enum addition at
those codes is not silently mislabelled again.

Ftype 33/34 are TQ1_0/TQ2_0 in the table and I left them alone; they
match the enum. Older llama.cpp builds briefly used 33/34 for the
Q4_0_4_4-family repacking types before those were removed, so if you ever see
a very old GGUF report TQ1_0, that is the reason — not something this PR
introduces.