[Feature]: Allow configuring pg_rewind --sync-method=syncfs

### Is there an existing issue already for this feature request/idea?

- [x] I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.

### What problem is this feature going to solve? Why should it be added?

CloudNativePG 1.30 invokes `pg_rewind` without exposing or passing its `--sync-method` option. As a result, `pg_rewind` uses the default `fsync` method.

In our environment, we operate a very large number of databases. This results in a PostgreSQL data directory containing millions of files. During failover recovery, the former
primary can therefore take a long time to rejoin the cluster.

With the default sync method, the final synchronization phase recursively opens and synchronizes every file in the data directory, WAL directory, and configured tablespaces. This
final phase can add significant recovery time when the file count is very high.

PostgreSQL 17 and later support:

```text
pg_rewind --sync-method=syncfs

### Describe the solution you'd like

Please expose an opt-in CloudNativePG configuration for selecting the pg_rewind sync method.

When configured as syncfs, the instance manager should invoke:

```text
pg_rewind --sync-method=syncfs ...
```

Suggested behavior:

- Keep fsync as the default for backward compatibility.
- Allow syncfs as an explicit opt-in.
- Support it for PostgreSQL 17 and later.
- Document that syncfs is Linux-specific and may flush unrelated data located on the same filesystem.
- Log the selected sync method when starting pg_rewind.
- Return a clear validation or compatibility error when the option is used with an unsupported PostgreSQL version.

The exact API field and location can follow the project's preferred configuration design.

### Describe alternatives you've considered

- Continuing to use the default fsync method is safe, but the final synchronization phase is very slow with millions of files.
- Running pg_rewind manually is operationally risky because CloudNativePG manages the instance lifecycle and recovery process.
- Rebuilding the replica from a new base backup can require substantially more time, storage I/O, and network traffic.
- Using --no-sync would weaken durability guarantees and is not an acceptable alternative.

### Additional context

The current CloudNativePG 1.30 implementation constructs the pg_rewind command with options such as:

```text
-P
--source-server
--target-pgdata
--restore-target-wal
```

It does not currently pass --sync-method.

PostgreSQL documentation:

https://www.postgresql.org/docs/current/app-pgrewind.html

### Backport?

Yes

### Are you willing to actively contribute to this feature?

No

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct