Build MinIO from source instead of depending on a registry mirror

[sgamelin]

Summary

This project's CI (via nisshi-io/nisshi's smoke job, which checks this
repo out and runs its docker compose stack) has been failing at
docker compose up: minio Error unauthorized: access to the requested resource is not authorized.

MinIO no longer distributes prebuilt binaries or container images for
anonymous/public use — dl.min.io now returns 410 Gone, and the
minio/minio Docker Hub repository is gone entirely (confirmed
directly). quay.io/minio/minio, pinned here, has also stopped serving
anonymous pulls.

Both MinIO's server and its mc client stay public because they're
AGPLv3-licensed, so this builds both ourselves from that source instead
of depending on any registry's redistribution of them:

• etc/minio/Dockerfile: clones the last tagged release of each (on
  their now archived, read-only upstream repos) and runs a plain
  go build, matching each project's own local build command rather
  than their release pipelines, which themselves depend on the now-dead
  dl.min.io downloads. mc is needed alongside the server because
  CI execs it inside the same container (docker compose exec minio /usr/bin/mc ...), matching the previous image's layout.
• compose.yaml: the minio service now builds that image instead of
  pulling a fixed reference.

Same fix as nisshi-io/nisshi#754,
applied here since this repo has its own separate compose.yaml and
minio pin.

Also included: stop routing local minio test credentials through secrets

.github/workflows/ci.yml sourced the mc/AWS_* credentials for the
ephemeral, local-only MinIO instance from ${{ secrets.AWS_ACCESS_KEY_ID }}/${{ secrets.AWS_SECRET_ACCESS_KEY }}, gated behind an integration
environment. These aren't real credentials — they're MinIO's default
root user/password for a container that only ever exists for the
duration of one CI job — so there's no reason to route them through
secrets, and nisshi-io/nisshi's own ci.yml already treats the
identical value as a plain literal (minioadmin).

Beyond being unnecessary, this was actively causing a problem while
testing this very fix: GitHub withholds secrets from pull_request runs
triggered by a fork (as this PR is, since I don't have push access here),
so every run on this PR failed at mc mb with Access Denied — the
mc/minio build itself worked fine (mc ready local succeeded), it
was purely the empty secrets breaking the next step. Switched both
occurrences to the literal minioadmin, and dropped environment: integration from the job since it had no protection rules configured
(confirmed via the API) and existed only to scope secret access.

Verification

Verified in the sibling fix for nisshi-io/nisshi (identical Dockerfile,
same MinIO/mc versions):

• docker compose build minio succeeds (~45s once the Go build cache is
  warm).
• docker compose up minio starts successfully and reports (healthy).
• The exact healthcheck command already in compose.yaml
  (timeout 5s bash -c ...) passes inside the built image — bash
  added to the minimal base image for this, since the previous
  (registry-pulled) image happened to include it.
• minio --version / mc --version both report their pinned release
  tags correctly.
• The S3 API's /minio/health/live endpoint returns 200.
• mc ready local, mc alias set, and mc mb (the exact commands CI
  runs) all succeed against the running container.
• This PR's own CI (example (ubuntu-latest, ...)) exercises the same
  docker compose up + mc sequence directly; confirmed the minio build
  itself succeeds there (mc ready local passed before the pre-existing
  secrets issue was found and fixed above).

Expected failure on this PR: every postgres://... matrix leg (pre-existing, unrelated to this change)

Every s3://nisshi/ leg passes; every postgres://postgres:postgres@db
leg fails, consistently, on every OS/Kafka-version combination. Root
cause is schema drift, not this change and not a timing flake:

etc/initdb.d/010-schema.sql in this repo predates several schema
changes already live in ghcr.io/nisshi-io/nisshi:main (a repartitioned
header table keyed on (topition, offset_id, ordinal) instead of
(id, record, k), and a virtual_topic table this repo's schema doesn't
have at all). Against the mismatched schema, produce fails silently
(tests/test-topic.bats's produce test doesn't check $status), which
cascades into the stale-offset/timeout/node assignment failures further
into the suite. Confirmed by reproduction: the identical test suite fails
3/3 runs against this repo's schema and passes 3/3 runs against nisshi's
current schema, with no other change.

This repo's own CI (ci.yml) has apparently never exercised the postgres
leg cleanly against a schema this far out of date — nisshi-io/nisshi's
smoke job doesn't hit it because that job copies nisshi's current
schema over this repo's before bringing the stack up.

Not fixed in this PR (scope is the minio/CI-credentials issue above) —
flagging clearly here so a reviewer doesn't mistake the postgres legs for
a regression from this change.

Risks / follow-ups

• Pinned to RELEASE.2025-10-15T17-29-55Z (minio) and
  RELEASE.2025-08-13T08-35-41Z (mc), the last officially tagged
  releases before each upstream repo was archived.
• No image caching across CI runs is set up for this; both Go builds are
  fast enough that this wasn't judged necessary.

🤖 Generated with Claude Code