fix(backups): platform-flow (useSystemBucket) in-place Postgres restore cannot converge past the chart's bootstrap guard #3327

Summary

An in-place restore of a platform-flow Postgres (backup.useSystemBucket: true) cannot converge: the RestoreJob's CNPG driver patches the app with bootstrap.enabled: true, but the chart hard-fails rendering when bootstrap.enabled && backup.useSystemBucket, and the driver's partial app schema can neither carry nor clear useSystemBucket. The app's HelmRelease is left failing until an operator manually flips backup.useSystemBucket off.

Flagged by IvanHunters during review of #3313 (#3313 (review)); it is pre-existing on main (both the guard and the patch shape predate that PR's merge-base), so it was split out rather than fixed there.

Evidence

• Chart guard (packages/apps/postgres/templates/db.yaml): {{- if and .Values.bootstrap.enabled .Values.backup.useSystemBucket }}{{- fail "postgres: bootstrap.enabled=true is incompatible with backup.useSystemBucket=true. Use a backups.cozystack.io/RestoreJob against the cozy-default BackupClass to restore from the system bucket; ..." }} — note the message recommends exactly the RestoreJob path that then trips this guard.
• Driver partial schema (internal/backupcontroller/postgresapp/types.go): PostgresSpec.Backup has no useSystemBucket field ("Add new fields here only when the driver genuinely needs them; everything else stays on the server, untouched by the controller's patches"), so the restore patch leaves the live useSystemBucket: true in place while setting bootstrap.enabled: true and the legacy restore coordinates.
• Result: the patched values combine bootstrap.enabled: true with useSystemBucket: true, the chart render fails, and the HelmRelease (remediation retries -1) loops on the same render error forever — the restore never completes and the guard's own error message is what the operator sees.

Impact

• Restoring a useSystemBucket: true Postgres in place (RestoreJob targeting the same release) wedges the release. Restore into a fresh release name works only if the new app is created without useSystemBucket.

Proposed fix (pick one)

• Add useSystemBucket to the driver's partial app schema and have the restore patch explicitly set it to false (the restore patch already supplies the full legacy coordinates, so the semantics stay consistent), restoring it after the bootstrap completes if desired; or
• Teach the chart to tolerate bootstrap.enabled && useSystemBucket when the restore coordinates are fully supplied (the guard exists to catch missing coordinates, not the driver-managed restore); or
• Have the driver clear bootstrap and re-assert useSystemBucket as part of restore finalization, making the combination transient by construction.