fix(gsm): support user (authorized_user) ADC via the official google-cloud SDK

[suzak]

Fixes #322.

What

Replace the google_secretmanager provider's backend — google-secretmanager1 (google-apis-rs) + yup-oauth2 — with Google's official SDK crates google-cloud-secretmanager-v1 and google-cloud-gax.

Why

The old client authenticated only with service-account keys. With gcloud auth application-default login (user / authorized_user credentials) and GOOGLE_APPLICATION_CREDENTIALS set, it failed with Bad service account key: missing field 'private_key' (see #322). google-cloud-auth's ADC resolver handles authorized_user, service-account, impersonated / external accounts and the metadata server out of the box, so the manual resolve_auth wiring is no longer needed.

Changes

• Remove resolve_auth(); build the client with SecretManagerService::builder().build().await (ADC resolved automatically).
• Map operations onto the official request builders: access_secret_version, list_secrets (via ItemPaginator), get_secret, create_secret, add_secret_version, delete_secret.
• put NOT_FOUND detection now uses err.http_status_code() == Some(404) instead of string-matching the error's Display.
• Drop the internal get_hub seam that leaked the backend hub type; the GSM trait keeps the list/get/put/del value-level seam (and its in-memory MockClient).
• Dependencies: google-secretmanager1 + crc32c → google-cloud-secretmanager-v1 + google-cloud-gax (google-cloud-auth is pulled in transitively).

Transport is HTTP/REST (reqwest) via gaxi; no gRPC/tonic is added for this crate.

Testing

• cargo check -p teller-providers — green.
• Built the CLI and ran it against a real Secret Manager project using gcloud user ADC, with GOOGLE_APPLICATION_CREDENTIALS set to the user ADC file (the exact case that failed before): teller show and teller run now resolve secrets successfully.
• Existing in-memory sanity_test unchanged.

Notes

• Contained to the google_secretmanager provider; the Provider trait, the registry and the other providers are untouched.
• The official crates require Rust 1.88+ / edition 2024. teller already builds on nightly, so there's no workspace MSRV regression, but this raises the effective floor for the google_secretmanager feature specifically — flagging in case that matters.
• Unrelated, found while testing: teller-core/src/exec.rs uses duct::cmd(Path::new(first), rest), which treats the program as a literal path, so teller run -- <bare-cmd> fails to resolve it via PATH (No such file or directory). Passing first (a &str) instead lets duct do the PATH lookup. Happy to send this as a separate PR.