VALID UNTIL password expiry versus client-certificate expiry for PostgreSQL role credentials

Goal

I want to choose a single credential‑expiry mechanism for application roles that follows least‑privilege principles, so that expiry behaves predictably and cannot be sidestepped by other authentication methods.

Constraints and uncertainty

PostgreSQL’s VALID UNTIL timestamp only blocks password‑based logins; it is ignored for cert, peer, trust and similar methods, allowing a role with an expired password to connect if pg_hba.conf permits those methods. Conversely, client‑certificate authentication enforces expiry during the TLS handshake but does not affect the stored SCRAM or MD5 verifier, so a valid certificate can be used with an expired password. The two paths therefore do not compose, and an expired password does not lock the role or trigger a self‑service reset because \password requires an already‑authenticated session.

Questions

• Is there a documented way to make password expiry and certificate expiry act together for a single role, or must I select exactly one mechanism?
• If I standardize on VALID UNTIL, what pg_hba.conf ordering or restrictions are needed to prevent non‑password methods from bypassing the expiry check?
• When a credential expires, which mechanism allows delegated recovery (e.g., password reset or certificate renewal) without requiring superuser privileges?