test: add patroni reinit integration test for versioned storage layout

[marceloneppel]

Issue

PR #1649 migrated all four storage mounts from bare mount roots to versioned 16/main subdirectories. During validation, patronictl reinit was found to fail when PostgreSQL data lives under the versioned path — Patroni's reinit rebuilds a replica by streaming a base backup from the primary, and this operation was broken when data resided at mount point roots (where lost+found and other artifacts interfere).

There was no integration test covering the patronictl reinit flow, so regressions in this path would go undetected.

Solution

Add a dedicated integration test (tests/integration/high_availability/test_patroni_reinit.py) that validates patronictl reinit works correctly with the versioned storage layout.

The test deploys a 3-unit PostgreSQL cluster with continuous writes, then:

1. Identifies a replica and confirms the cluster is healthy with writes flowing.
2. Stops Patroni on the replica, deletes pg_control to simulate data corruption, and restarts Patroni — PostgreSQL fails to start.
3. Verifies Patroni logs record the pg_control startup failure.
4. Runs patronictl reinit to rebuild the replica from the primary via base backup.
5. Confirms the replica recovers to running/streaming state, that pg_control is present at the versioned path (/var/snap/charmed-postgresql/common/var/lib/postgresql/16/main/global/pg_control), and that data integrity is maintained across all units.

Also adds the corresponding spread task (tests/spread/test_patroni_reinit.py/task.yaml) for CI execution.

Checklist

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