The Dockerfile split core into its own RUN so the nine images would share
it. Measuring the built result showed they did not: only 4 of 11 layers
were shared, and each image carried its own ~7 GB copy. An identical
`pip install` does not write identical bytes (dist-info metadata, RECORD
files), so the layer digests differ even when the command and inputs
match. Sharing by coincidence does not work.

Dockerfile.capability-base builds the core (OS + apt + torch + the
import-time deps) ONCE as its own image, and each profile is FROM it, so
the sharing is structural. build_capability_image.sh builds it on first
use and reuses it after (REBUILD_CORE=1 to force, needed when core.txt
changes).

Measured after rebuilding all nine: every image now carries all 8 core
layers and adds 2 of its own (audio 5, from its build-deps apt churn).
29 distinct layers instead of 67, local disk 40.9 GB instead of 94, and a
push uploads the 6.79 GB core once rather than nine near-identical
copies. A pod pulling a second capability image already has most of it.

Also corrected the publish script's claim that `gh` could make the
packages public: GitHub's Packages REST API is list/get/delete/restore
only, there is no visibility endpoint, and new packages are always
private. It now prints the per-package settings URLs and says plainly
that this is a click each.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY