Verify the RDS certificate in dr restore's psql

Epic 5916 AC6.1 required every CP DB client, "tools that connect" included, to connect with TLS required AND the server certificate verified. Child 5941 (#5159) moved the API path to `sslmode=verify-full` with a pinned RDS CA bundle, but named one tool it left behind. Observed (Finish 5948): `tools/dr_restore.py:93` `real_psql` sets `"PGSSLMODE": "require"` — encrypted but unverified — when it connects to the restored-snapshot RDS instance. The sibling tool already does it right: `tools/cp_psql.sh:226` exports `PGSSLMODE="${PGSSLMODE:-verify-full}" PGSSLROOTCERT="$ca_bundle"` (bundle fetched as in that script, ~:170). The API pins the bundle path/sha in `apps/api/app/db_credentials.py:45-52` / `infra/local/Dockerfile.api`. Fix: make `real_psql` use `PGSSLMODE=verify-full` with `PGSSLROOTCERT` pointing at the RDS global CA bundle, obtained the same way `cp_psql.sh` obtains it (reuse, don't re-invent; if the bundle is absent, fail loudly with an actionable message rather than silently downgrading). The restored instance's endpoint hostname must be what psql connects to so verify-full matches the cert — confirm the conninfo uses the endpoint name, not an IP. Out of scope: the API/DSN path, `cp_psql.sh`, terraform, the restore procedure's other steps, and any change to `require` fallbacks elsewhere. Done means: - A unit test in the dr_restore tests asserts `real_psql`'s child env carries `PGSSLMODE=verify-full` and a `PGSSLROOTCERT` path (and that a missing bundle raises an actionable error). - `grep -n '"require"' tools/dr_restore.py` → no hit. - `./dc check full` green; PR merged to develop; Jaah Deploy green on dev.

dr_restore's psql now uses verify-full with the RDS CA bundle (shared cp_psql cache, fails loudly if absent, refuses a shared cache dir). Full gate green, PR #5182 merged, Jaah Deploy dev green. Follow-up: same cache-dir check in cp_psql.sh.