docs(local-model): pinning digests changes the catalogue's no-digest rule

The weekly check's report and docs ask for an optional `digest` on each catalogue row, but the
catalogue keeps no digest on purpose: test/local-model-catalog.test.ts ("holds no download
data") refuses a `sha256` anywhere in it. Say so where the digest contract is described, so a
maintainer reads it as a decision for the catalogue, not a quick schema change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/local-models.md

@@ -282,7 +282,9 @@ For every model row it checks:
   exactly that name, or the check never compares it. Until then the report lists today's
   digests, rows with measured figures first, because without a digest a rebuild of about the
   same size goes unnoticed (a switch between the mlx and the gguf build does not: their sizes
-  differ by 2% or more).
+  differ by 2% or more). Pinning digests is a decision, not a quick fix: today the catalogue
+  holds no digest on purpose, and `test/local-model-catalog.test.ts` ("holds no download
+  data") refuses a `sha256` anywhere in it, so that rule changes with it.
 
 For the runtime pin it checks whether a newer Ollama release exists, and whether the pinned
 `ollama-darwin.tgz` is still on GitHub with the pinned size and sha256.

scripts/check-local-model-catalog.mjs

@@ -44,9 +44,12 @@
  * manifest a Mac pulls, which is the value `/api/tags` reports after the pull (`sha256:<hex>` or
  * the bare hex). The catalogue schema does not have that field yet: `LocalModelEntrySchema` is
  * strict, so it must gain an optional `digest` before a row can carry one, under exactly that
- * name, or this check never compares it. Until then the report lists the digests to pin, and
- * a rebuild of about the same size goes unnoticed (a change of build, mlx against gguf, never
- * does: every pair seen so far differs by 2% or more, far past the size tolerance).
+ * name, or this check never compares it. The catalogue keeps no digest today on purpose
+ * (test/local-model-catalog.test.ts, "holds no download data", refuses a `sha256` in it), so
+ * pinning digests changes that rule too: a decision for the catalogue, not for this script.
+ * Until then the report lists the digests to pin, and a rebuild of about the same size goes
+ * unnoticed (a change of build, mlx against gguf, never does: every pair seen so far differs
+ * by 2% or more, far past the size tolerance, and a row that names its runner is held to it).
  *
  * Everything that reaches the report from the network is validated first (digests, sizes,
  * runner and format names, version tags), because the workflow puts the report in an issue.