fix(backups): clear useSystemBucket on Postgres in-place restore - #3573

What this PR does

Fixes #3327.

A Postgres app created with the platform-recommended backup.useSystemBucket=true
flow cannot be restored in place on main. The failure is by construction:

1. The CNPG restore driver (buildPostgresAppRestorePatch) writes explicit backup
   coordinates onto the target CR (destinationPath / endpointURL /
   s3CredentialsSecret / endpointCA) and flips bootstrap.enabled=true — i.e.
   it converts the app to the explicit-coordinates (legacy) backup flow, which is
   exactly what the chart's bootstrap.recovery + externalClusters block needs.
2. But the driver never cleared the server-side backup.useSystemBucket=true. The
   partial postgresapp.Backup struct had no such field, so the JSON merge patch
   left it untouched.
3. On the next render the chart trips its own guard
   (bootstrap.enabled=true is incompatible with backup.useSystemBucket=true,
   packages/apps/postgres/templates/db.yaml). The HelmRelease drops into a
   permanent render-error, bootstrap.recovery never renders, and the RestoreJob
   can never converge — precisely the "cannot converge" symptom in the issue.

Fix: clear backup.useSystemBucket in the restore patch so the chart receives a
self-consistent value set (explicit coordinates, no system-bucket flag, recovery on).
The new postgresapp.Backup.UseSystemBucket field intentionally omits omitempty:
otherwise the false zero-value is dropped from the merge patch, the server's true
survives, and the bug persists. The chart guard is left in place — it is still correct
defensive behavior for a genuinely broken combo; this change stops the driver from
producing that combo.

Verification

• Unit tests: new TestBuildPostgresAppRestorePatch_ClearsUseSystemBucket asserts both
  the struct flip and that the raw merge patch serializes "useSystemBucket":false
  (guards the omitempty regression directly). Full internal/backupcontroller
  package green; go vet clean.
• helm template of packages/apps/postgres with the exact values the driver now
  produces (bootstrap.enabled=true, useSystemBucket=false, explicit coords):
  • before / bug (useSystemBucket=true) → render fails on the guard at
    db.yaml:150.
  • after / fixed (useSystemBucket=false) → renders the full recovery topology:
    bootstrap.recovery.source, externalClusters → -recovery ObjectStore, plus the
    ongoing backup ObjectStore.

Screenshots

n/a — controller-internal change, no UI.

Downstream repositories

Walked the trigger map in docs/agents/contributing.md file-by-file against the diff.
The change touches only internal/backupcontroller/ (the CNPG restore driver and its
partial mirror struct) — no CRD (Package/Plan/RestoreJob are untouched), no chart
values (useSystemBucket already exists in the postgres chart), no annotation and no
telemetry metric. Nothing downstream is affected.

• No downstream repository is affected by this change

Release note

fix(backups): a Postgres application using the platform `backup.useSystemBucket=true` flow can now be restored in place — the CNPG restore driver clears `useSystemBucket` so the chart's bootstrap guard no longer wedges the HelmRelease in a permanent render error.