[MISC] Fix cluster initialize on primary

[sinclert-canonical]

This PR fixes a subtle bug, where upon cluster initialization, the primary instance was waiting on Patroni member_started, instead on the primary endpoint being available.

This approach falls short when performing further operations on the _start_primary method, as the default database cannot be connected to when trying to list users / groups (see failing CI job). The problem has been surfaced after correctly closing the connection on the PostgreSQL list_users charm lib method.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.54%. Comparing base (d35b18d) to head (693d97d).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #826   +/-   ##
=======================================
  Coverage   72.54%   72.54%           
=======================================
  Files          15       15           
  Lines        3893     3893           
  Branches      589      589           
=======================================
  Hits         2824     2824           
  Misses        885      885           
  Partials      184      184           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sinclert-canonical]

Subordinate charm tests will remain failing until we fix the PostgreSQL vs UbuntuPro base desync.

Feel free to ignore.

[sinclert-canonical]

Closing PR. Alternative fix proposed in PostgreSQL charm lib (see PR)