fix(test): use proxy's configured database port in advisory lock test

client_a was hardcoded to PG_PORT (5532) while the proxy may connect to
a different PostgreSQL instance (e.g. postgres-tls:5617 in TLS CI). This
meant the advisory lock was held on a different server than client_b was
targeting, so the lock never blocked and the test was flaky in CI.

Use get_database_port() to ensure client_a connects to the same
PostgreSQL instance the proxy uses.

Author: tobyhede

packages/cipherstash-proxy-integration/src/common.rs

@@ -272,7 +272,7 @@ where
 }
 
 /// Get database port from environment or use default.
-fn get_database_port() -> u16 {
+pub fn get_database_port() -> u16 {
     std::env::var("CS_DATABASE__PORT")
         .ok()
         .and_then(|s| s.parse().ok())

packages/cipherstash-proxy-integration/src/connection_resilience.rs

@@ -7,7 +7,7 @@
 /// - Blocked backend connections don't affect other proxy connections
 #[cfg(test)]
 mod tests {
-    use crate::common::{connect_with_tls, PG_PORT, PROXY};
+    use crate::common::{connect_with_tls, get_database_port, PROXY};
     use std::time::Instant;
     use tokio::task::JoinSet;
     use tokio::time::{timeout, Duration};
@@ -128,7 +128,8 @@ mod tests {
 
         let result = timeout(Duration::from_secs(30), async {
             // Connection A: hold an advisory lock (connect directly to PG to avoid proxy interference)
-            let client_a = connect_with_tls(PG_PORT).await;
+            let pg_port = get_database_port();
+            let client_a = connect_with_tls(pg_port).await;
             client_a
                 .simple_query(&lock_query)
                 .await