bug(1.30.0): align PostgreSQL startup ordering with lease acquisition on primary restart

When the instance manager reconciles a pod whose `PGDATA` is already flagged as primary and which Kubernetes already designates as `targetPrimary`, it starts PostgreSQL as soon as system initialisation completes.

Lease acquisition happens afterward, inside the `Cluster` reconcile loop, only once `IsReady()` has already confirmed PostgreSQL is up. `targetPrimary == podName` reflects Kubernetes' intent, not proof that a previous holder of the role has actually released it (e.g. a prior primary process still running after a node partition or slow termination), so starting PostgreSQL ahead of the lease means this code path offers no fencing against that scenario.

The promoted-replica path is unaffected: the lease is already acquired there before `pg_promote` is invoked, so this gap is specific to the restart-on-already-primary-PGDATA path. Reaching the race in practice requires a node partition or delayed termination combined with asynchronous replication. With synchronous replication, the recommended production configuration for avoiding data loss, the client-visible commit is gated on standby acknowledgment, which the affected instance can't obtain while partitioned, so this is a gap specific to async-only setups rather than a general regression of the lease feature.

*Note:* affects 1.30.0 only, introduced by #10627, not present in 1.29.x or earlier since the primary lease mechanism doesn't exist there.