feat(security): integrate HashiCorp Vault for secrets management (#17)

[dreamgene]

Summary

Closes #17

Replaces plaintext environment variables for sensitive secrets (DB password, Anchor secret) with a secure HashiCorp Vault integration, eliminating the risk of secret leakage through logs or process dumps.

---

Changes

• src/secrets.rs — New SecretsManager service that authenticates with Vault via AppRole on startup and exposes methods to fetch secrets dynamically.
• src/config.rs — Updated config::load() to source db_password and anchor_secret from Vault instead of environment variables.
• Cargo.toml — Added vaultrs crate for Vault API integration.
• docker-compose.yml — Added a local Vault dev server for development and testing.

---

How It Works

1. On startup, the app authenticates with Vault using AppRole credentials (VAULT_ROLE_ID, VAULT_SECRET_ID).
2. SecretsManager fetches secrets from the secret/ KV v2 mount.
3. Secrets are passed into Config at load time — no plaintext secrets ever touch env vars or config files.

---

Testing

1. Start the local Vault instance:

   docker compose up -d vault
   

2. Seed secrets and configure AppRole (see setup instructions in the issue).
3. Set VAULT_ADDR, VAULT_ROLE_ID, and VAULT_SECRET_ID in your environment.
4. Run:

   cargo build && cargo test
   

---

Security Notes

• No secrets are hardcoded or committed to the repo.
• VAULT_ROLE_ID and VAULT_SECRET_ID should be injected at runtime via a secrets manager (e.g. Kubernetes Secrets, CI/CD vault injection) — not stored in .env files.
• Vault token TTL is set to 1h with a 4h max, limiting exposure in case of token leakage.

---

Checklist

• Feature branch created from develop
• SecretsManager service implemented
• config::load() updated
• Local Vault setup documented
• Builds without errors (cargo build)
• Tests pass (cargo test)
• No secrets committed to the repo

[Mac-5]

Please, you are to make your pr against the develop branch not main, resolve conflicts