docs(backups): correct the PostgreSQL PITR window and base-backup selection #716

Follow-up to cozystack/cozystack#4443, which corrects docs/operations/backup-classes.md (PostgreSQL PITR) in the main repository. The website carries its own copy of that page in content/en/docs/next/operations/services/backup-classes.md and content/en/docs/v1.6/operations/services/backup-classes.md, and both repeat the parts #4443 found wrong.

Applies to released versions (next/ and v1.6/)

• The recoverable window. The upper bound is described as "the timestamp of the most recent WAL segment shipped to object storage". It is the last transaction (commit or abort) in the archived WAL: a time-targeted recovery ends just before the first transaction after the target, and a segment switch or a base backup is not one. On a database at rest, every instant after its last write fails with recovery ended before configured recovery target was reached.
• The "safe" fallback. The page recommends restoring "at/before the most recent completed backup". On a database at rest that instant is past the last transaction and fails the same way. The state as of the last write is obtained by omitting recoveryTime.
• Aiming at stoppedAt. status.stoppedAt is truncated to the second, while the plugin compares recoveryTime with barman's end time to the microsecond and keeps only a backup that ended at or before it. A recoveryTime equal to stoppedAt misses that backup, falling back to an older one or to no target backup found. Aim at least one second past it.
• Archives with several timelines. PostgreSQL follows recovery_target_timeline: latest through the consecutively numbered history files it finds. A missing .history confines the replay to the backup's own timeline, and a latest timeline that is a sibling stops recovery with requested timeline N is not a child of this server's history.

Applies only once #4443 is released

• A RestoreJob starts from the base backup its Backup names (recoveryTarget.backupID), except for a recoveryTime earlier than one second past that backup's end, and except when its cnpg.io/Backup is gone (then a BaseBackupGone warning event is recorded).
• A base backup removed from the bucket by a lifecycle rule or by hand stays pinned until the plugin's maintenance pass deletes its cnpg.io/Backup, and deleting that cnpg.io/Backup by hand is the way out.

The corrected text is in the #4443 diff of docs/operations/backup-classes.md, sections "The recoverable window", "Discovering the earliest / latest restorable time" and "Archives with several timelines".