[Rollout] Adopt reusable signed Docker build (cosign + SBOM) across all product repos

[BryanFRD]

Goal

Every product image is cosign-signed + has an SBOM (and Trivy + hadolint). The machinery already exists in reusable-docker-build.yml — this is about adoption: the product repos still run bespoke Buildah docker.yml and don't call it. Direction decided: migrate them to the reusable (buildx) workflow.

Blocking prerequisites (P0 — must land before touching any product repo)

1. Merge reusable-docker-build.yml to main of FerrLabs/.github. It's only on feat/reusable-ferrflow-release today, so uses: …@main can't resolve.
2. Secret build-arg support. The product builds pass NODE_AUTH_TOKEN (private GHCR npm read). The reusable workflow's build-args input is plaintext → would leak the token in logs. Add:
   • a secrets: block (e.g. packages-read) on the workflow_call,
   • pass it to build-push-action via secrets: (BuildKit --mount=type=secret), not build-args,
   • update each Dockerfile that consumes the token: ARG NODE_AUTH_TOKEN → RUN --mount=type=secret,id=packages-read ….
3. Platforms per package. Reusable defaults to linux/amd64,linux/arm64. The Rust APIs build single-arch today; multi-arch under QEMU is slow/fragile. Set platforms: linux/amd64 for API packages (revisit arm64 later).
4. Site changelog prefetch. Buildah builds clone FerrLabs/Changelog into the context first (chroot has no network). Under buildx (network available) either keep a pre-step or fetch in the Dockerfile.

Per-repo migration recipe (after P0)

For each docker.yml build job:

• Replace the inline buildah steps with uses: FerrLabs/.github/.github/workflows/reusable-docker-build.yml@main.
• Inputs: image-name, tag (from the release tag), dockerfile, context, runner: ferrlabs-k8s-large, platforms, build-args (non-secret only), extra-tags (major.minor, latest).
• secrets: packages-read: ${{ secrets.FERRFLOW_PACKAGES_READ }}.
• Keep the release-tag triggers (site@v*, app@v*, api@v*).

Repos to migrate

FerrVault-Cloud, FerrTrack-Cloud, FerrGrowth-Cloud, FerrAgents (FerrFleet-Cloud), FerrLens-Cloud, FerrGames-Cloud, FerrLabs-Cloud, FerrFlow-Cloud, Status, Finance (already partly on it).

Validation

None of this is testable in isolation — each migration is validated on that repo's next real release. Do FerrVault first as the reference; fan out only once it's proven green on a release. Don't migrate all at once (a broken release pipeline = can't ship).

Sequence

1. P0 fixes to the reusable workflow (+ Dockerfile secret-mounts) — this PR-set unblocks everything.
2. FerrVault-Cloud reference migration → validate on a release.
3. Fan out to the rest, one PR per repo.