Switch from full graphical xfreerdp sessions to /auth-only mode which
verifies NLA credential injection without needing a display server.
Fix unreachable-target by creating the resource while the container is
alive then terminating it before connecting. Drop reconnect and
session-duration tests to match the depth of other PAM resource tests.

freerdp2 treats EAGAIN on the first BIO_read as fatal rather than
retrying, so if the gateway is still fetching credentials when xfreerdp
connects the transport fails immediately. Retry up to 3 times on
ERRCONNECT_CONNECT_TRANSPORT_FAILED to give the bridge time to start.

freerdp2 treats EAGAIN on the first BIO_read as fatal, which always
fails through the multi-hop proxy tunnel. freerdp3 handles this
properly. The test already prefers xfreerdp3 over xfreerdp, so just
install freerdp3-x11 in CI instead of freerdp2-x11.

Start Xvfb and export DISPLAY in CI so xfreerdp3 runs directly without
the xvfb-run shell wrapper. Use container.Host(ctx) for the resource
host instead of getOutboundIP, matching the pattern used by SSH,
Postgres and Redis tests. Increase xfreerdp timeout to 60s.

Pre-connect to the RDP proxy and verify the Rust bridge is ready with
an X.224 handshake probe before letting xfreerdp connect. This avoids
the race where freerdp's non-blocking BIO_read gets EAGAIN because the
multi-hop tunnel hasn't finished setting up the bridge yet.

Adds a direct-xrdp-connection subtest that runs xfreerdp /auth-only
directly against the xrdp container with no proxy chain. This will
show whether the CI failures are caused by xrdp/NLA configuration
in Docker or by the multi-hop proxy chain.

The /auth-only flag fails against xrdp because xrdp sends a license
error blob that freerdp3 treats as fatal, even though NLA succeeded.
Switch to full graphical sessions that are held for a few seconds then
killed. If the process stays alive past the hold time, the connection
is considered successful.

Also removes warmBridgeProxy since the transport failure was caused by
the /auth-only license issue, not a bridge startup race.

…ency

In production sdl-freerdp's GUI initialization gives the proxy chain
time to establish the tunnel before the first packet. In tests xfreerdp
connects instantly and hits EAGAIN. Retry up to 3 times with a 2s delay
on ERRCONNECT_CONNECT_TRANSPORT_FAILED to handle this.

Adds a proxy-tcp-debug subtest that connects a raw TCP socket to the
proxy, sends X.224 CR, and measures timing of the round trip. This will
show exactly how long the proxy chain takes to respond and whether the
issue is timing or something else.

The proxy returns EOF after 39ms instead of X.224 CC. Something in the
chain is failing and closing the connection. Dump the proxy command's
stderr to see the actual error.

The proxy logs no error, just "connection closed". The failure is on
the gateway side where the bridge/handler runs. Dump both proxy and
gateway output to see the actual error.

The setupRecordingConfig function inserted a recording config with a
random connectionId that doesn't map to any real app connection. When
the gateway tried to fetch session credentials, the backend followed
the bogus connection ID and returned 404. This was the actual cause of
all the proxy chain failures, not timing or bridge startup.

…recording config

The backend requires a recording config for Windows resources. The
previous implementation used storageBackend 'aws-s3' with a fake
connectionId, which broke the credentials API (404 on app connection
lookup). Now creates a dummy app connection row to satisfy the FK
constraint and uses storageBackend 'postgres' which never resolves the
connection at runtime.

Replace direct DB insertion with LocalStack-based setup. The upstream
backend now rejects postgres storage for Windows resources and requires
a decryptable app connection. LocalStack handles both STS
GetCallerIdentity (app connection validation) and S3 HeadBucket/PutObject
(recording config validation).

The backend S3 client uses virtual-hosted-style addressing which fails
in Docker (bucket.localstack doesn't resolve). Create the app connection
via API (STS works fine) then insert the recording config row directly
into Postgres, skipping the HeadBucket/PutObject validation.

…tion

Replace direct DB insertion with proper API calls. Add bucket name as a
Docker network alias on the LocalStack container so the backend's S3
client can resolve virtual-hosted-style hostnames (bucket.localstack).
Set LOCALSTACK_HOST=localstack so LocalStack parses the bucket name
from the Host header.

Network alias approach didn't resolve virtual-hosted-style S3 hostnames.
Direct DB insert bypasses S3 validation entirely and is simpler. App
connection still created via API for proper KMS encryption.