[DPE-10841] feat(database): publish client endpoints from the manager (3/7)

[marceloneppel]

Issue

Third slice of the postgresql_provider.py migration. The client relation's read/write and read-only endpoints are still published by the charm, which is why ConfigManager currently calls back through a refresh_endpoints bridge.

Solution

Completes managers/database.py with update_endpoints(), plus CharmState.replicas_endpoint alongside the primary endpoint it already exposed.

The two substrates compute the addresses differently and both forms are kept:

• VM reads the online Patroni members, skips members tagged nosync, takes the leader's database-address as the read/write endpoint and the replicas' as the read-only ones, falling back to the primary when there are no replicas.
• K8s reads the <app>-primary and <app>-replicas Services.

One behaviour change. The read-only connection URI is now built from the read-only hosts rather than the read-only endpoints. On K8s, ro_endpoints already carried :5432, and interpolating it into the URI template published a second one. Reproduced on postgresql-k8s 16/edge rev 943 against data-integrator:

uris:           postgresql://relation_id_4:…@postgresql-k8s-primary.<model>.svc.cluster.local:5432/<db>
read-only-uris: postgresql://relation_id_4:…@postgresql-k8s-primary.<model>.svc.cluster.local:5432:5432/<db>

No client can dial that host. VM built the same URI from the port-less ro_hosts and was correct; both substrates now use that form.

Unit tests are in PR 6, including a case that asserts a single port in the read-only URI.

Stacked on 2/7. Next: 4/7.

Checklist

• I have added or updated any relevant documentation.
• I have cleaned any remaining cloud resources from my accounts.