Is your feature request related to a problem? Please describe.
When using External Secrets Operator (ESO) with Google Secret Manager (GSM), fetching a secret fails if the secret has multiple versions where the latest version is destroyed but an older version is still enabled.
Example: a secret has versions 1 (enabled) and 2 (destroyed). ESO appears to check both versions/latest and the latest active version; the call against versions/latest fails because that points to the destroyed v2, causing the whole fetch to fail even though v1 is valid.

Describe the solution you'd like
Have ESO/GSM provider gracefully handle destroyed latest versions by:

• Providing an option/flag to prefer “latest enabled” over “latest” when no explicit version is specified, or
• Ignoring destroyed versions during resolution unless a specific destroyed version was explicitly requested.

Describe alternatives you've considered
Pinning an explicit version (e.g., version: "1"). This works but defeats the purpose of tracking the newest enabled version automatically.
Re-creating a new version to become the latest (e.g., v3) so versions/latest is valid again. This is operationally clunky and easy to forget.

Additional context
Repro steps:

• Create a GSM secret with version 1 (enabled).
• Add version 2, then destroy version 2.
• Configure an ExternalSecret that references the secret without specifying a version (i.e., relies on latest).
• ESO sync fails because the provider attempts to read versions/latest, which points to destroyed v2.
  Expected: ESO should successfully read version 1 (latest enabled) or otherwise not fail when the latest is destroyed.
  Observed logs (representative): request to projects/.../secrets//versions/latest fails due to destroyed version; sync marked as error.