fix(frank-large): load the model as its native 3-way split, not a concatenated file

The first cutover crash-looped the unit with 'invalid split file name':
the fetch script concatenated the three split parts into a single GGUF,
but part 1's header carries ggml.file_count=3, so the byte-correct
concatenation still advertises itself as a split and the loader demands
a -NNNNN-of-NNNNN filename.

- serve-frank-large.sh: -m points at part 1; llama.cpp loads the split
  natively (parts 2-3 auto-discovered in the same directory)
- deploy-remote.sh: LLM_LARGE_MODEL gate path follows
- download-frank-large-unsloth.sh: assembly removed; the parts ARE the
  canonical payload, verified against live Hub LFS oids
- docs: runbook model section + troubleshooting note, AGENTS.md, log
- the redundant 87 GiB assembled file is staged on dankclaw at
  ~/.AGENTTRASH/20260921-frank-large-assembled/

scripts/serve-frank-large.sh

@@ -51,10 +51,16 @@ if [[ ! -x "$SERVER_BIN" ]]; then
     exit 1
 fi
 
-MODEL_FILE="$MODEL_DIR/Qwen3.8-Flash-Next-UD-IQ4_XS.gguf"
+# Point -m at the FIRST split part, not a concatenated file: the parts
+# carry ggml.file_count=3 metadata in part 1's header, so even a
+# byte-correct concatenation still advertises itself as a 3-way split and
+# the loader rejects a non-split filename ("invalid split file name").
+# With -m on part 1, llama.cpp loads the 3-way split natively (parts 2-3
+# are auto-discovered in the same directory).
+MODEL_FILE="$MODEL_DIR/UD-IQ4_XS/Qwen3.8-Flash-Next-UD-IQ4_XS-00001-of-00003.gguf"
 if [[ ! -r "$MODEL_FILE" ]]; then
     echo "missing target model: $MODEL_FILE" >&2
-    echo "fetch and assemble it: bash $SCRIPT_DIR/download-frank-large-unsloth.sh" >&2
+    echo "fetch it: bash $SCRIPT_DIR/download-frank-large-unsloth.sh" >&2
     exit 1
 fi