sec(deps): bump pgx/v5 to v5.9.2 to clear GO-2026-5004 govulncheck advisory #1285

The Security Scanning CI gate has been failing on main since at least 2026-06-26 with:

```
Vulnerability #1: GO-2026-5004
SQL Injection via placeholder confusion with dollar quoted string literals
in github.com/jackc/pgx
Module: github.com/jackc/pgx/v5
Found in: github.com/jackc/pgx/v5@v5.8.0
Fixed in: github.com/jackc/pgx/v5@v5.9.2
Example traces found:
#1: internal/database/connection.go:353:25: database.Connection.ReleaseAdvisoryLock
calls pgxpool.Conn.QueryRow, which eventually calls sanitize.SanitizeSQL
```

govulncheck classifies this as a real call-graph hit (not just an import) because
`database.Connection.ReleaseAdvisoryLock` reaches `sanitize.SanitizeSQL` through
`pgxpool.Conn.QueryRow`. We don't pass attacker-controlled SQL into that path
(the only argument is a deterministic int64 lock key), so this is unlikely
exploitable in CUDly today, but it keeps the Security Scanning gate red on every
PR -- which is itself a problem (real future findings drown in the noise).

Fix

Bump `github.com/jackc/pgx/v5` from v5.8.0 to v5.9.2 in the root `go.mod` and
re-run `go mod tidy`. Verify with:

```bash
go install golang.org/x/vuln/cmd/govulncheck@v1.1.4
for mod in . pkg providers/aws providers/azure providers/gcp tests/e2e; do
echo "==> govulncheck in $mod"
(cd "$mod" && govulncheck ./...)
done
```

Out of scope here

The Security Scanning CI gate also runs across the per-cloud submodules; check
each one for the same advisory after the root bump and lift versions in sync if
needed (PR #1277 surfaced this; the lint-flood issue is tracked separately in
#1223).