fix(gallery): raise arch-router scoring output cap via parallel:64

Scoring decodes the whole prompt+candidate in a single llama_decode and
reads one logit row per candidate token. The vendored llama.cpp server
caps causal output rows at n_parallel, so the default of 1 aborts with
GGML_ASSERT(n_outputs_max <= cparams.n_outputs_max) on multi-token route
labels. Set options: [parallel:64] on both arch-router quant entries to
lift the cap; kv_unified (the grpc-server default) keeps the full context
per sequence, so this does not split the KV cache.

Assisted-by: claude-code:claude-opus-4-8 [Claude Code]
Signed-off-by: Richard Palethorpe <io@richiejp.com>

Author: richiejp

gallery/index.yaml

@@ -24475,6 +24475,14 @@
     # concurrent generation traffic; see model_config.go validation).
     known_usecases:
       - score
+    # Scoring decodes the whole prompt+candidate in one llama_decode and reads
+    # a logit row per candidate token. The llama.cpp server caps the causal
+    # output rows at n_parallel, so the default (1) aborts with
+    # GGML_ASSERT(n_outputs_max <= cparams.n_outputs_max). Raise it to cover
+    # multi-token route labels; kv_unified (the grpc-server default) keeps the
+    # full context per sequence, so this does not split the KV cache.
+    options:
+      - parallel:64
     parameters:
       model: Arch-Router-1.5B.Q4_K_M.gguf
   files:
@@ -24486,6 +24494,9 @@
   overrides:
     known_usecases:
       - score
+    # See the q4 entry: lift the scoring output-row cap above the default 1.
+    options:
+      - parallel:64
     parameters:
       model: Arch-Router-1.5B.Q8_0.gguf
   files: