ci: use setup-sqlx-cli composite in 5 workflows

[rnegron]

Problem

sqlx-cli is installed via a hand-copied cargo install line in 7 places across 5 CI workflows. A setup-sqlx-cli composite action already exists for exactly this and is used 4 times in ci-backend.yml; these callsites just never adopted it. Maintaining the install flags (version, features, --locked) in 7 spots is drift-prone.

Changes

Swap the 7 raw installs for uses: ./.github/actions/setup-sqlx-cli:

• ci-agent-skills.yml (×2)
• ci-mcp.yml
• ci-e2e-playwright.yml
• ci-ai.yml
• cd-sandbox-base-image.yml

The composite builds the identical binary (0.8.0, --features postgres --no-default-features --locked) and adds an explicit version-keyed actions/cache with a cache-hit guard, so cold-cache jobs skip the build. No change to which jobs run or when.

Leaves ci-nodejs.yml untouched — it installs with --features native-tls,postgres, which the composite doesn't build. Covering it would need a features input on the composite (separate change).

How did you test this code?

I'm an agent. No manual testing. I validated that all 5 changed workflows parse as YAML (yaml.safe_load) and that the diff is a pure 1:1 swap with no other edits. CI's own actionlint and the affected workflow runs are the real verification.

Publish to changelog?

no

🤖 Agent context

Authored by Claude Code.

[greptile-apps]

_{Reviews (1): Last reviewed commit: "Merge branch 'master' into rauln/ci-sqlx..." | Re-trigger Greptile}

[stamphog]

Gates denied this PR because it touches CI/CD workflows, which are on the deny-list. This requires human review regardless of the change's apparent simplicity.

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-05-27 21:03 UTC	Run
prod-us	✅ Deployed	2026-05-27 21:21 UTC	Run
prod-eu	✅ Deployed	2026-05-27 21:22 UTC	Run