fix: CI/packages hardening sub-slices — pin action SHAs + --all guard (#88), manifest .part/top-level-gguf (#89)

[mvalancy]

Accumulated review follow-ups on the #88 (CI/CD) and #89 (packages) epics, landed as one minimal PR. Each sub-slice was independently re-verified against the code before fixing.

#88.1 — assert --all in the artifact validator

What: tightened tests/test-ci-artifacts.sh's workflow-lockstep grep from git bundle create to git bundle create .*--all.
Why: the bundle must be full-history — bootstrap.sh does a plain git clone <bundle>. A future edit dropping --all would ship a shallow, unclonable bundle yet still pass the old bare-substring grep.
Test: verified the tightened grep matches the real release.yml (has --all) and does NOT match a copy with --all stripped → CI would fail on the regression. test-ci-artifacts.sh 24/0.

#88.2 — pin GitHub Actions to commit SHAs

What: pinned every action in ci.yml + release.yml to the full commit SHA the tag points at, each with a trailing # vN marker:

• actions/checkout@v7 → @9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7
• actions/setup-node@v7 → @820762786026740c76f36085b0efc47a31fe5020 # v7
• actions/upload-artifact@v7 → @043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
• softprops/action-gh-release@v3 → @3d0d9888cb7fd7b750713d6e236d1fcb99157228 # v3

Why: a floating major tag silently follows whoever moves it — supply-chain exposure in a public repo. The SHA-pinned form is the hardened standard; dependabot still bumps it. Behavior/versions unchanged, only the ref is pinned. SHAs resolved via gh api repos/<owner>/<action>/commits/<tag> (dereferences the annotated action-gh-release tag to its commit; the actions/* tags are lightweight → commit directly), each cross-verified against both the refs and commits endpoints.
Test: added a floating-tag lint in test-ci-artifacts.sh (^…uses:…[^#]*@v[0-9], [^#]* so the # vN comment never trips it) that fails if any workflow regresses to @vN; confirmed it stays quiet on the pinned+comment form and fires on a floating sample.

#89.3 — filter in-progress / .part dirs from /api/packages

What: computePackages (sections 1 & 3) now skips a *.part single-file partial and a tool/model directory mid-extraction — one still holding a .tmp_* archive temp (written by download_and_extract, removed only on a successful extract), via a new _pkgInProgress() helper.
Why: the ZIM enum already excludes foo.zim.part, but the app/model enums listed every non-dotfile entry — so a half-fetched model.gguf.part or a mid-extraction dir (reporting size 0) was advertised as a ready package.
Test: test-packages.sh now seeds a partial .gguf.part (in a category and at top level), a mid-extraction app dir and a mid-extraction model dir → asserts none appear; proven to leak against the pre-fix server.

#89.4 — enumerate top-level single .gguf files

What: added a pass over the model root listing each top-level *.gguf file (models/<name>.gguf, no category dir) as model:<name> → /api/archive/models/<name>.
Why: getModelsStatus supports that flat layout, but the manifest only descended into category directories, silently dropping top-level models. Requiring the .gguf suffix keeps a *.gguf.part partial out for free.
Test: test-packages.sh seeds models/toplevel.gguf → asserts it's listed with the right size/url; proven absent against the pre-fix server. test-packages.sh 8/8.

Learnings

Baked into docs/knowledge/gotchas.md under distinct anchors: ci-sha-pin-88, pkg-inprogress-89, pkg-toplevel-gguf-89.

Notes

Zero-dep server preserved; web UI untouched; no network in tests (the only network was the one-time gh api SHA lookups during implementation). These epics have more slices — not a full fix.

Part of #88
Part of #89

🤖 Generated with Claude Code