fix(compose): point MinIO at quay.io — the Docker Hub repository is gone

[acamarata]

This is a live product outage, not a CI failure

MinIO removed minio/minio from Docker Hub. Every nSelf stack with MINIO_ENABLED=true can no longer pull its storage image:

minio Error pull access denied for minio/minio, repository does not exist
or may require 'docker login': denied: requested access to the resource is denied

Measured today:

check	result
hub.docker.com/v2/repositories/minio/minio/	{"message":"object not found"}
manifest minio/minio:RELEASE.2024-01-16T16-07-38Z, anonymous	401
manifest minio/minio:RELEASE.2024-01-16T16-07-38Z, authenticated	401
manifest minio/minio:latest	401
quay.io/minio/minio — same three tags, anonymous	200

Authenticating does not help — I tested with valid Docker Hub credentials. The repository is gone, not rate-limited and not gated, so a docker/login-action step would have been the wrong fix.

internal/compose/images.go is the generator behind every user's docker-compose.yml, so this is not limited to our CI. It surfaced as a red job in nchat (Accessibility E2E Tests, run 34837167497), which starts a real nself stack.

Changes

1. MinIO → quay.io. One MinioImagePath constant, used by both the DefaultImageVersions pin and buildMinioService's MINIO_VERSION path — they formatted the name independently before and could drift. MINIO_VERSION semantics are unchanged.

2. nhost/functions:0.3.7 → :latest. Found by the same sweep. That tag has never existed (nhost's 0.x line stops at 0.1.9; tags are now <node-major>-<version>, e.g. 22-2.2.0). Nothing broke, because the entry is unreachable: applyDefaultsFunctions sets FUNCTIONS_VERSION=latest when unset, so ResolveImage never falls back to the pin. latest is what users actually run, so naming it makes the pin honest and changes no emitted compose file. Picking a real 2.2.0 pin is an upgrade decision, deliberately not made here.

3. A gate so this cannot recur silently. .github/workflows/default-images-pullable.yml resolves every DefaultImageVersions entry daily with docker manifest inspect. The list is generated from the map itself (tools/imagelist), so a new pin is covered the moment it lands — no second list to forget. It's a manifest lookup, not a pull: no registry credentials, and no warm layer cache that could hide a dead pin. This is the gate whose absence let a pin rot: it was valid when written, and nothing re-checked it.

4. Docs + examples. Core-Services.md, Service-Graph.md, Config-Custom-Services.md, and the CS_N_IMAGE examples that used minio/minio as a digest-pinning illustration.

Verification

$ go run ./tools/imagelist | while read svc img; do docker manifest inspect $img …; done
ok  admin/auth/functions/hasura/mailpit/meilisearch/minio/mlflow/nginx/postgres/redis/typesense   (12/12)
gate_exit=0

Exercised in the failing direction — MinioImagePath reverted to minio/minio:

FAIL  minio  minio/minio:RELEASE.2024-01-16T16-07-38Z -- denied: requested access to the resource is denied
gate_exit_with_regression=1

--- FAIL: TestMinioImageIsRegistryQualified
--- FAIL: TestBuildMinioService_UsesQuayRegistry/explicit_version
--- FAIL: TestBuildMinioService_UsesQuayRegistry/empty_version_defaults_to_latest

gofmt clean, go vet clean, go test ./internal/compose/... ./internal/config/... ./internal/build/... → 612 passed.

Follow-up (not in this PR)

Existing installs carry the dead image in their already-generated docker-compose.yml and need nself build re-run. Worth a nself doctor check that flags an unresolvable service image; filed separately rather than bolted on here.

Reference apps (nchat, ntask, admin) pin minio/minio in their own compose files and k8s manifests — fixed per repo, tracked alongside this.