fix: run the TLS integration harness under a containerized job

The `migration-smoke` job fails on the Gitea runner at
`docker port ekklesia-database-tls-<pid> 5432` with
`no public port '5432' published`; the later invalid-URL and
`ECONNREFUSED 127.0.0.1:5432` failures all cascade from it.

Gitea executes the job inside a container and drives sibling containers
through the runner's Docker daemon. The harness held two host-only
assumptions, both reproduced in a nested job container and fixed here.

Bind-mount source paths are resolved by the daemon against the runner
host's filesystem. The certificate directory is created in the job
container's `/tmp`, which does not exist there, so the daemon silently
creates an empty directory, the entrypoint's `cp` fails, the container
exits, and `docker port` reports no published port for an exited
container. The material is now transferred with `docker cp` into the
created-but-not-yet-started container, which crosses the daemon boundary
correctly in both topologies, and only the server leaf and its key are
transferred — both CA private keys stay in the harness directory.

A published port lands on the runner host's loopback, a different
network namespace from the job container's; measured, a container the
daemon published at `127.0.0.1:32907` is `ECONNREFUSED` at that address
from inside the job container. Under a containerized job the harness now
publishes nothing and joins both containers to one isolated user-defined
network, reaching PostgreSQL by container DNS on 5432. Direct-host runs
keep a random port pinned to loopback via Docker's `127.0.0.1::5432`
form. `compose_job_network_job_container` exports the topology decision
the integration script already made, so there is still exactly one
detector.

Every TLS assertion is preserved, and the certificate identity is
generated from the host actually connected to — `localhost` directly, the
container's DNS name otherwise. The mismatch and chain-only controls use
the TLS container's address on the isolated network rather than a
hardcoded one, and the certificate carries no IP SAN, so verify-full
still fails with `ERR_TLS_CERT_ALTNAME_INVALID`.

Correcting one measurement in passing: chain-only verification does not
skip the identity check. For an IP host `pg` omits `servername` and hands
`tls.connect` a bare socket with no host, and `net.Socket._host` is null
for an IP literal, so Node checks the fixed fallback name `localhost` —
never the address dialled. A certificate whose only SAN is
`DNS:example.invalid`, reached chain-only over `127.0.0.1`, is rejected
with `Host: localhost. is not in the cert's altnames`. The direct-host
control therefore only ever passed because its SAN was `DNS:localhost`.
The SAN set now always includes that fallback name so the control proves
the same gap in both topologies, and the stale claim is corrected in the
transport doc comment. No production behavior changes.

Teardown also removes the container's anonymous volume, the isolated
network, and the job container's attachment, after success and failure
alike.

Co-Authored-By: Claude Opus 5 <[email protected]>

core/src/database/transport.ts

@@ -191,12 +191,13 @@ export function assertNoConnectionStringTlsParameters(databaseUrl: string): void
  *
  * `verify-full` is **not** simply `ssl: true` or `{ rejectUnauthorized: true }`. Verified directly
  * against a live TLS PostgreSQL instance: those verify the certificate *chain*, but `pg` only sets
- * `options.servername` for non-IP hosts (`pg/lib/connection.js`), and Node performs no identity
- * check at all when `servername` is unset — so a certificate issued for an entirely different name
- * is accepted when connecting to an IP address. Supplying an explicit `checkServerIdentity` pinned
- * to the configured host closes that gap for DNS and IP hosts alike (proven: a certificate valid
- * only for `localhost` is rejected with `ERR_TLS_CERT_ALTNAME_INVALID` when reached via
- * `127.0.0.1`).
+ * `options.servername` for non-IP hosts (`pg/lib/connection.js`) and passes `tls.connect` a bare
+ * socket carrying no host, so for an IP endpoint Node has no identity to check and falls back to
+ * the fixed name `localhost` — never the address actually dialled. A certificate issued for an
+ * entirely different name is therefore accepted when connecting to an IP address. Supplying an
+ * explicit `checkServerIdentity` pinned to the configured host closes that gap for DNS and IP hosts
+ * alike (proven: a certificate valid only for `localhost` is rejected with
+ * `ERR_TLS_CERT_ALTNAME_INVALID` when reached via `127.0.0.1`).
  */
 export function databaseTlsConnectionOptions(
   databaseUrl: string,