feat(async-replication): promotion flow, standby lifecycle, and actions (4/8)

[marceloneppel]

Issue

Completes the events handler ported in 3/8: the promotion flow and the standby lifecycle.

Solution

• _can_promote_cluster, _handle_forceful_promotion, _handle_replication_change (K8s re-emits the relation-changed event, VM does not — divergence preserved; per-substrate "unit/pod addresses" action messages preserved);
• promote_to_primary (VM reports "Creating replication...", K8s "Promoting cluster..." — divergence preserved);
• _on_async_relation_changed flow helpers: _handle_late_joiner, _wait_for_all_units_stopped, _publish_stop_marker (VM-only: publishes the highest counter into the relation databag so the demoted cluster's primary-side pre-check can compare it), _start_standby_database (K8s gates on the pebble service, VM retries start_patroni);
• _configure_primary_cluster (VM's other-cluster-stopped pre-check preserved) and _configure_standby_cluster (VM suppress-oversee-users flag vs K8s Patroni-resource deletion);
• _stop_database/_stop_patroni_with_retries/_reinitialise_pgdata/_clear_pgdata (K8s-only, with the standby-pgdata-cleared tracking), _handle_database_start/_handle_leader_database_start, _wait_for_standby_leader, _re_emit_async_relation_changed_event.

Complexity stays under the repo's C901=10 by the helper extraction above; substrate branches are inline and commented.

Faithfulness note: _stop_database keeps the VM charm's original behaviour — pgdata and the raft state are cleared on every unit during demotion, not only the leader — while K8s keeps the leader-first pattern with the standby-pgdata-cleared deferral for non-leaders.