feat: add GCP Cloud KMS backend, make secrets backend a runtime toggle

[itsharshvb]

Summary

• Adds GCP Cloud KMS as a third key-management backend alongside AWS KMS and HashiCorp Vault. src/crypto/gcp.rs implements the Crypto trait directly against the google-cloud-kms SDK, mirroring src/crypto/aws.rs's shape exactly (inline SDK calls, no intermediate abstraction) — src/services/gcp/config.rs is a thin config + client holder, same role as src/services/aws/config.rs.
• Backend selection moves from a compile-time-flag-driven cfg!() precedence chain to a config-driven runtime toggle: secrets.manager = "aws_kms" | "gcp_kms" | "hashicorp_vault" | "aes_local" in TOML, mirroring hyperswitch/hyperswitch-card-vault's SecretsManagementConfig pattern. aws/vault/gcp are now real optional-dependency feature gates, so any combination can ship in one binary and config decides which backend runs at startup.
• Secrets::create_keymanager_client now returns a Result and propagates client-construction failure with ?, instead of panicking internally — matching hyperswitch's own get_encryption_management_client (crates/external_services/src/managers/encryption_management.rs). The panic boundary moved to the actual boot call site in SessionState::from_config (src/app.rs), which already panicked there for thread-pool build failures.
• src/crypto/kms.rs renamed to src/crypto/aws.rs — "kms" was ambiguous once GCP KMS existed too; matches src/crypto/gcp.rs's naming.
• New docs/encryption-key-management-flow.md: the two-layer architecture (bootstrap secrets vs. live DEK management), why cripta uses one trait pair instead of hyperswitch's two, the envelope-encryption data flow, a backend comparison table, and an extension checklist for adding a future backend.
• config/development.toml currently points secrets.manager at a real AWS KMS key (account 143555788000, region ap-south-1) with the DB password re-encrypted as AWS KMS ciphertext; aes_local is left commented as a credential-free fallback. A GCP KMS dev key was also configured and fully verified earlier in development before switching the committed example to AWS.
• config/development.toml and config/config.example.toml both document (commented out by default) a filtering_directive required when manager = "aws_kms" — see "Notes for reviewers" below.

Test Plan

• cargo hack check --each-feature --all-targets — clean on stable and MSRV 1.92.0
• cargo clippy --all-features --all-targets -- -D warnings — clean
• cargo test --all-features — passes
• cargo +nightly fmt --all --check — clean
• Live end-to-end round trip against a real GCP KMS dev key: app boot, POST /key/create → POST /data/encrypt → POST /data/decrypt, confirmed data_key_store.source = GcpKms
• Live end-to-end round trip against a real AWS KMS key (via SSO-assumed-role credentials): same flow, confirmed data_key_store.source = KMS

for aws

for Gcp