Mirror node add rerun skips shared Postgres initialization after partial install failure

[JeffreyDallas]

Problem

When solo mirror node add fails after installing the shared resources chart but before mirror-node Postgres initialization completes, a retry can skip the internal Postgres setup tasks.

The retry sees the existing solo-shared-resources Helm release and sets installSharedResources=false. The mirror-node flow currently uses that flag to skip both:

• Initialize Postgres pod
• Prime mirror-node postgres secret

That leaves the shared Postgres pod running, but without the mirror-node database roles/users initialized. The later mirror-node pods can then fail readiness because the expected DB users were never created.

Root Cause

installSharedResources means "the shared-resources Helm release needs to be installed in this run". It does not mean "the internal shared Postgres is already initialized for mirror-node".

The Postgres initialization path is already designed to be idempotent through the solo-initialized database comment sentinel, so it should run for internal database deployments even when the shared-resources chart already existed before the current run.

Expected Behavior

For internal database deployments, mirror-node add/upgrade should always prime the mirror password secret and invoke shared Postgres initialization. The initialization code should decide whether work is needed.

For external database deployments, these shared Postgres tasks should still be skipped.

[JeffreyDallas]

Follow-up from the latest performance run: Postgres now schedules, but Redis was still Pending because the performance cluster also taints target nodes with solo.hashgraph.io/role. Redis had the propagated owner/network selector and tolerations, but not the role scheduling.

PR #4650 now includes a third fix: when Redis does not define role scheduling explicitly, shared-resource chart values inherit the solo.hashgraph.io/role node selector/toleration from mirror-node component values such as importer, grpc, rest, restjava, web3, or monitor. Explicit Redis values still take precedence.

[JeffreyDallas]

Migration CI follow-up from PR #4650: the failure was separate from Redis scheduling. The Postgres init wrapper checked the database sentinel with obj_description, which does not read PostgreSQL database comments. On mirror-node upgrade, the wrapper missed the existing solo-initialized sentinel, treated the DB as partial, and reinitialized it. Commit d730739a2 switches the sentinel read to shobj_description and also cleans up the mirror_rest role during true partial recovery.