fix: the web service starts once libpq can be found.

ADR.md

@@ -359,16 +359,22 @@ missing. PostgreSQL may also start after the services at boot.
 Decision: The web service makes its signing key and creates the refresh tokens' database itself,
 and the Router Manager its sessions database; neither `vpn-router-setup` nor a maintainer script
 creates them. Each service does it before it listens, retrying every 15 seconds and logging each
-failure, then listens. The first step is the PostgreSQL driver: psycopg finds libpq through the
-linker cache, which the package manager refreshes only at the end of an installation, so a
-service started during the installation cannot import it yet. The Manager imports psycopg only in
-its retry loop. On the router, `vpnrouter_auth` alone imports it, in `driver()`, which the web
-service's retry loop calls first, and turns a failed import and every database failure into
+failure, then listens. `vpnrouter_auth` turns every failure of the database into
 `DatabaseError`, the only database exception the web service and `vpn-router-user` handle.
 
+psycopg (Ubuntu ships only its pure-Python implementation) finds libpq through the dynamic linker
+cache, which dpkg refreshes with its deferred `ldconfig` only at the end of an installation, so a
+service started during the installation cannot import it yet; a failed import cannot be repeated
+in the same process either, as psycopg caches the lookup. The services therefore import psycopg
+plainly, and their units wait instead: `ExecStartPre=wait-for-libpq`, a shell script of each
+package, waits until `ldconfig -p` lists `libpq.so.5`, within `TimeoutStartSec=5min`. The
+maintainer scripts start the units with `systemctl --no-block` (debhelper's start is turned off),
+because a start that waited would hold dpkg before its `ldconfig`.
+
 Consequences: The order of installation and of the start of PostgreSQL and of the linker cache
-does not matter; a driver that cannot be loaded or a database that cannot be created is retried
-until the cause is gone, and the reason is in the service's log, without restarts. The web unit may write `/etc/vpn-router` for the key and the database password.
+does not matter; a database that cannot be created is retried until the cause is gone, and the
+reason is in the service's log. Outside an installation the wait ends at once. The web unit may
+write `/etc/vpn-router` for the key and the database password.
 
 ## ADR-17: Bootstrap diagnostics run only until the first setup succeeds