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/

tests/frank_large_unit.bats

@@ -85,9 +85,10 @@ REMOTE_DEPLOY="$REPO_ROOT/scripts/deploy-remote.sh"
     grep -q 'unsloth/Qwen3.8-Flash-Next-GGUF' "$FETCH"
     grep -q -- '-fL -C -' "$FETCH"
     # The LFS oids come from the Hub tree API at verify time, not from a
-    # file that could drift.
+    # file that could drift; each part's local sha256 is compared to its
+    # oid and a mismatch fails the run.
     grep -q 'tree/main' "$FETCH"
-    grep -q 'sha256sum -c SHA256SUMS' "$FETCH"
+    grep -q 'SHA256 MISMATCH' "$FETCH"
 }
 
 @test "the fleet endpoint and alias survive the cutover" {