[DPE-10841] feat(database): client-relation manager and its mapping caches (1/7)

[marceloneppel]

Issue

postgresql_provider.py still lives in both charms (VM 645 lines, K8s 606, near-identical), and the config flow it feeds already moved into this library. Until the provider follows, update_config has to be handed a relations_user_databases_map and a user_hash the charm computes from provider state, and it calls back into the charm to refresh client endpoints. This is the first of six PRs that move the whole client relation here; it carries the state the config flow already reads.

Solution

Adds managers/database.py with the parts of the provider that are pure state:

• the custom-username and prefixed-database caches, kept under the same app-secret labels (custom-usernames, prefix-databases) so deployed clusters keep their existing content;
• the relation-to-database mapping;
• collect_user_relations() and user_hash, which the config manager consumes in PR 4 in place of the two injected values;
• are_units_in_sync(), the peer-hash comparison the request handler defers on;
• get_plugins(), ported from both charms unchanged.

The generated PostgreSQL role name is derived from the substrate rather than converged: VM clusters hold roles named relation-<id> and K8s ones relation_id_<id>, so a single name would require renaming roles on every deployed K8s cluster. utils/postgresql.py already matches both forms in its relation-user SQL.

Nothing constructs this manager yet — PR 4 wires it in. Unit tests are in PRs 5 and 6, following the split used for the update_config migration.

Stacked on #189. Next: 2/7.

Checklist

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