[Bccorb]

Closes #473. Closes #474.

#473: compose stack on loopback, no default owner

• docker-compose.yml: the API is published as 127.0.0.1:${API_PORT:-5312}:5312, and Postgres is no longer published (only the API container reaches it over the compose network). I checked the docs and scripts for anything that reaches the quickstart Postgres from the host and found none; the README now points at docker compose exec postgres psql -U seamless seamless_auth for a shell. POSTGRES_PORT no longer applies to this file.
• OWNER_EMAIL has no default (${OWNER_EMAIL:-}), so the owner grant is off unless it is set. I chose this over requiring it so docker compose up (and docker compose config) still work with no environment; the README quickstart now leads with OWNER_EMAIL=you@example.com docker compose up and explains that without it nobody is granted admin. validateEnvs.sh does not check OWNER_EMAIL, and src/lib/ownerAdmin.ts already treats an empty value as unset.
• docker-compose.dev.yml had the same exposure, so it gets the same treatment: API and Postgres on 127.0.0.1, no OWNER_EMAIL default. Postgres stays published there (on loopback) because CONTRIBUTING documents running the suite with TEST_DB=postgres.
• docs/configuration.md (development mode section) and README.md note the bind address and why (Docker publishing bypasses host firewalls such as ufw).

docker compose config output, both files: the API port renders with host_ip: 127.0.0.1, the quickstart Postgres has no ports, the dev Postgres renders host_ip: 127.0.0.1, and OWNER_EMAIL renders as "" (or the passed value with OWNER_EMAIL=me@example.com).

#474: pinned release supply chain

• Dashboard ref. SEAMLESS_ADMIN_DASHBOARD_REF is now e16c1e84e6a105fb7cadc328570a2fbc469f463d, the commit of dashboard tag v0.10.1 (the tag already pinned; it is a lightweight tag, confirmed with git ls-remote and the refs API). The tag is kept in the comment above the ARG. The build refuses a ref that is not a full 40-character SHA and, after checkout --detach, checks git rev-parse HEAD against it. Verified locally: docker build --target admin-dashboard . succeeds, and --build-arg SEAMLESS_ADMIN_DASHBOARD_REF=v0.10.1 fails with "SEAMLESS_ADMIN_DASHBOARD_REF must be a full commit SHA". There was no existing check in scripts/ or tests/ that parses this ARG; the seamless-cli SEAMLESS_ADMIN_DASHBOARD_REF is an unrelated env var in that repo. docs/configuration.md describes the new bump procedure.
• Actions pinned to commit SHAs with the exact version as a trailing comment, across every workflow. Each SHA is the commit the previously used floating tag points to today, so the code that runs is unchanged (annotated tags dereferenced; none of these were annotated):
  • actions/checkout v7.0.1, actions/setup-node v7.1.0, codecov/codecov-action v7.1.1
  • docker/setup-buildx-action v4.4.1, docker/login-action v4.6.0, docker/metadata-action v6.2.0, docker/build-push-action v7.4.0
  • aquasecurity/trivy-action v0.36.0, sigstore/cosign-installer v3.9.1, github/codeql-action/* v4.39.1
  • changesets/action v2.1.2 (@v2 was a branch, currently identical to the v2.1.2 tag)
• Conformance workflow pinned to fells-code/seamless-cli v0.25.1 (66cb013). main is two commits ahead of that tag, but neither touches verify-conformance.yml, and the workflow still checks out the CLI at its own cli-ref input, so behaviour is the same.
• ci.yml gets top-level permissions: contents: read.
• Dependabot for github-actions already exists in .github/dependabot.yml (weekly, grouped), so no change; it updates SHA pins and their version comments.
• cosign identity. SECURITY.md and docs/production-operations.md already document the narrowed identity ^https://github\.com/fells-code/seamless-auth-api/\.github/workflows/docker-publish\.yml@refs/(heads/main|tags/v.*)$. The one place still printing the broad ^https://github.com/<repo>/ regexp was the job summary in docker-publish.yml, which now prints the same narrowed form. That is a text-only change to the summary step.

Note on the issue's suggested identity

The issue suggests verifying against docker-publish.yml@refs/tags/v* only. That would reject every current release. Releases are cut by release.yml on main, which calls docker-publish.yml as a reusable workflow (a tag pushed with GITHUB_TOKEN does not trigger the tag-push path; the last tag-push run of docker-publish was v0.7.3 in August). For a reusable workflow, Fulcio's SAN is the called workflow at the caller's ref. I read the signing certificate on the published v0.19.4 / latest image from GHCR and its identity is https://github.com/fells-code/seamless-auth-api/.github/workflows/docker-publish.yml@refs/heads/main. So the documented regexp keeps heads/main (real releases) plus tags/v.* (a tag pushed by hand), and still rejects any other workflow or branch.

Not changed

• What the workflows do: only uses: refs, the ci.yml permissions block, and the summary text changed.
• actionlint was not run locally (not installed); the Lint workflows job in this PR runs it.

Checks

• npm run typecheck: pass
• npm run lint: pass
• npx prettier --check .: pass
• npm run build: pass
• npm run coverage: pass, 141 files, 1977 tests passed (1 todo), thresholds met (98.9% statements, 95.4% branches, 99.2% functions, 99.13% lines)
• npm run check:changeset-bump: no major changesets
• docker compose config and docker compose -f docker-compose.dev.yml config: valid, output as described above
• docker build --target admin-dashboard .: pass; with a tag as the build arg: fails as intended