[DPE-10882] feat(database): own the client relation events, drop the endpoint bridge (4/7)

[marceloneppel]

Issue

The manager from PRs 1–3 has no observers, and ConfigManager still reaches back into the charm to refresh endpoints and is still handed a user hash the charm derives from provider state.

Solution

Adds events/database.py, which owns DatabaseProvides, observes database-requested, relation-departed and relation-broken, and constructor-injects the interface into DatabaseManager — the same shape as the TLS handler and its certificate requirers.

Each handler keeps its readiness guard and its work in one observer. defer() is per-observer, so splitting a guard from the action it protects lets a deferred action retry alone against state its guard never re-checked. That is the same failure mode as the TLS reload race in canonical/postgresql-k8s-operator#1618.

The two substrates' guards differ and both are kept. A request waits on the cluster being initialised plus, on VM, a started member and a reachable primary; on K8s, primary_endpoint_ready. A removal waits on the same predicate on VM, but on K8s settles for a started member. The K8s handler also wrote the primary Service endpoint, URI and TLS fields inline before update_endpoints ran; that write is preserved so databag write ordering is unchanged, though it may be redundant (need to validate in https://warthogs.atlassian.net/browse/DPE-10890) — the provider library emits database_requested on the leader only, and update_endpoints publishes the same values immediately after. Each substrate also keeps its own defer log wording.

One smaller divergence is deliberate: the endpoint refresh after a request narrows to the requesting relation on VM, while K8s keeps its whole-relation refresh — each exactly as its charm had it.

One parity gap is fixed up-stack rather than here: the requested_entity_secret_content read needs the ModelError guard the charms wrapped their whole _get_credentials in, because the vendored property raises while a cross-model grant is still pending.

Seam changes:

• ConfigManager takes the DatabaseManager and calls update_endpoints() itself. The refresh_endpoints charm bridge is deleted.
• update_config's user_hash parameter is gone; the manager derives it from the same relation data the user-databases map comes from. relations_user_databases_map stays injected — its computation lives in charm.py and diverges between substrates, so it belongs to the core event-loop phase.
• AbstractPostgreSQLCharm gains set_unit_status, update_config and primary_endpoint. The first routes status writes through the charm_refresh priority gate and stays until the refresh logic itself migrates into the library; the other two are reclaimed by later phases.

Follow-up lib PRs:

• [DPE-10883] test(database): cover the manager's mapping caches and user map (5/7) #220
• [DPE-10884] test(database): cover the manager's user lifecycle and endpoints (6/7) #221
• [DPE-10885] test(database): cover the client-relation events handler (7/7) #222

Wiring up at:

• [DPE-10886] refactor(relations): adopt the single-kernel client relation postgresql-k8s-operator#1696
• [DPE-10887] refactor(relations): adopt the single-kernel client relation postgresql-operator#1900

Checklist

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

[akram09]

Why it is initialized here? shouldn't be in the Charm ?