fix(ci): GHCR lowercase image owner + correct rollout env var (CI deploy has been failing on every push)

[acedatacloud-dev]

Why

Every push to main since this workflow was first written has produced a failed deploy workflow run. Two separate bugs stacked on each other:

Bug 1 — GHCR rejects mixed-case repository names

github.repository_owner on this repo evaluates to AceDataCloud (mixed case). The workflow's env block baked that into the image name:

env:
  IMAGE_API: ghcr.io/${{ github.repository_owner }}/x402guard-api

GHCR refuses, error verbatim from CI:

ERROR: failed to build:
  invalid tag "ghcr.io/AceDataCloud/x402guard-api:25625033998":
  repository name must be lowercase

Net effect: zero images have ever been pushed to ghcr.io/acedatacloud/x402guard-{api,web} by CI. The live x402guard.acedata.cloud is running whatever was hand-deployed at hackathon time. PRs #18 / #19 merged but their changes are not running in production.

Bug 2 — rollout step env var name mismatch

Even if bug 1 hadn't blocked us, the rollout step would have applied manifests with image tag local:

- name: Deploy
  env:
    GITHUB_RUN_ID: ${{ github.run_id }}     # ← passed here
  run: bash deploy/run.sh

…but deploy/run.sh reads:

TAG="${BUILD_NUMBER:-local}"                # ← reads here

So BUILD_NUMBER is unset → TAG=local → kubectl apply of image: ghcr.io/acedatacloud/x402guard-api:local → ImagePullBackOff. Caught only because rollout was gated on vars.DEPLOY_TO_K8S == 'true' (which is currently not set, so this leg never actually ran).

Fix

.github/workflows/deploy.yaml:

1. Drop the env-level IMAGE_API / IMAGE_WEB. Add a step that lower-cases the owner once and exposes the full image name via $GITHUB_OUTPUT. Build steps reference ${{ steps.names.outputs.image_{api,web} }}.
2. Rename GITHUB_RUN_ID → BUILD_NUMBER in the rollout step's env block to match deploy/run.sh.

Verified deploy/production/{api,web}.yaml already use lowercase ghcr.io/acedatacloud/x402guard-{api,web}:${TAG}, so the manifests resolve correctly once the image actually exists.

After this lands

Push trigger	Today	After this PR
images job builds + pushes	❌ fails on tag-case error	✅ pushes ghcr.io/acedatacloud/x402guard-{api,web}:<run_id> + :latest
rollout job (when vars.DEPLOY_TO_K8S=true is set)	would have applied :local	✅ applies :<run_id> matching what was just pushed
rollout skipped (default)	n/a	n/a — comment about gating preserved

To enable the rollout leg you still need to set:

• repo variable DEPLOY_TO_K8S=true
• repo secret KUBECONFIG (base64-encoded kubeconfig with acedatacloud namespace access)
• bootstrap secret x402guard-secrets in the cluster (deploy/run.sh checks for this and exits 1 if missing — see comment block at top)

This PR doesn't flip those — only fixes the build so the next person who flips them gets a working pipeline.

Why now

PRs #18 (envelope scheme:"exact") and #19 (CLI demo + README) only matter on main if production actually picks up main. Right now production has never picked up any main commit via CI. This PR is the missing link before anyone can verify the fix end-to-end against x402guard.acedata.cloud.

Verification

Workflow YAML still parses (no syntax change in the structure, only refactored interpolation).

Cannot test the rollout leg from here — needs the platform team's KUBECONFIG secret. The build step's success on first run after merge will be the real verification.