chore(ci): run tests against Multigres

[fadymak]

Runs tests against Multigres in parallel.

[blacksmith-sh]

Found 5 test failures on Blacksmith runners:

Failures

Test	View Logs
github.com/supabase/auth/internal/hooks/hookspgfunc/TestDispatch	View Logs
github.com/supabase/auth/internal/indexworker/TestIndexWorker	View Logs
github.com/supabase/auth/internal/indexworker/TestIndexWorker/ TestUserOptInWithZeroThreshold	View Logs
github.com/supabase/auth/internal/storage/TestConnLimits	View Logs
github.com/supabase/auth/internal/storage/TestConnLimits/applyPercentageLimits	View Logs

[depthfirst-app]

⚪ Severity: LOW

The latest tag is mutable and unpinned. If the multigres GitHub org or registry is compromised, a malicious image could be silently pushed and would execute arbitrary code in the CI runner — potentially exfiltrating repository secrets. The other service images in this workflow (postgres:15, orioledb/orioledb:beta16-pre-2-pg17) use pinned versions.
Helpful? Add 👍 / 👎

💡 Fix Suggestion

Suggestion: Pin the multigres-cluster image to a specific immutable version tag or SHA256 digest instead of using :latest. First, identify the desired release version or obtain the current image digest by running: docker pull ghcr.io/multigres/multigres-cluster:latest && docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/multigres/multigres-cluster:latest. Then replace :latest with either a specific version tag (e.g., ghcr.io/multigres/multigres-cluster:v0.1.2) or a full digest pin (e.g., ghcr.io/multigres/multigres-cluster@sha256:<hash>). This follows the same pinning practice already used by the other service images in this workflow (postgres:15 and orioledb/orioledb:beta16-pre-2-pg17).