bootstrap.idps / bootstrap.networks changes in config are silently ignored once the database is populated #2612

Component: wallet-gateway-remote and its Helm chart
Version: @canton-network/wallet-gateway-remote@1.10.0. The same code path is present at 1.11.2.
Store: Postgres

Summary
The Helm chart exposes identity providers and networks under config.bootstrap.idps and config.bootstrap.networks, so they look like the deployed configuration. In fact they are only read the first time the store is set up. Once the idps and networks tables have rows, changes to these values are ignored when you run helm upgrade or restart the pod. Nothing warns you about this, and the running gateway keeps using whatever is in the database.

Steps to reproduce

1. Deploy the gateway against an empty Postgres store with bootstrap.idps[0].issuer = A.
2. Change bootstrap.idps[0].issuer (or configUrl, or any bootstrap.networks[*] field such as auth.audience, clientId or ledgerApi.baseUrl) to B.
3. Run helm upgrade and wait for the pod to restart.
4. Call listIdps / listNetworks, or log in with a token issued by B.

Expected
The gateway uses B. Or, if seed-only is intended, it fails or warns clearly that the config differs from the stored state and is being ignored.

Actual

• The gateway keeps using A.
• Tokens from B are rejected with No identity provider found for issuer: B.
• The startup log only says No pending database migrations found. Nothing indicates that the bootstrap config was skipped or that it differs from the database.

Why this is a problem

• Misleading: the Helm values look like the source of truth, but in any existing environment they are not. Operators change values, see a successful deploy, and nothing changes.
• Config drift: the values file and the database disagree with no warning. A rebuilt environment behaves differently from the one it replaced.
• The only built-in way to force a re-seed loses data. Re-seeding requires emptying idps or networks. Because of networks.identity_provider_id → idps.id ON DELETE CASCADE and wallets.network_id → networks.id ON DELETE CASCADE, that deletes every user's wallets.
• Inconsistent secret handling: the config file references secrets indirectly through clientSecretEnv. Changing values at runtime through addNetwork requires a plaintext clientSecret, which is then stored in networks.admin_auth.
• The workarounds are manual: you have to call addNetwork / IDP upserts on the User API, which needs server.admin, or run direct SQL UPDATEs against the store.