fix(secrets): stay silent when Bitwarden enabled but unconfigured

[konsisumer]

What does this PR do?

Stops the repeated Bitwarden Secrets Manager: ... BWS_ACCESS_TOKEN is not set warning from printing on every Hermes startup for users who never actually set up Bitwarden Secrets Manager.

When secrets.bitwarden.enabled is true but neither an access token nor a project_id is configured, the integration was never set up — the warning is pure noise. We now return a clean (no-error) result in that case so nothing is printed. The token / project_id warnings still fire once setup is partway done (one of the two present), where they're genuinely actionable.

Note on the two other options the reporter suggested: both are already in main. The default config ships secrets.bitwarden.enabled: false (hermes_cli/config.py), and the status line is already deduplicated to print once per process via the applied-home guard added in #32271. This PR closes the remaining gap for configs that have enabled: true with nothing else filled in.

Related Issue

Refs #32715

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• agent/secret_sources/bitwarden.py: in apply_bitwarden_secrets, return early with a clean FetchResult (no error) when enabled but both the access token and project_id are empty, so no warning is emitted.
• tests/test_bitwarden_secrets.py: add test_apply_unconfigured_is_silent covering the no-token + no-project_id case; existing test_apply_missing_token (has project_id) and test_apply_missing_project_id (has token) still assert the warning fires when setup is partway done.

How to Test

1. With a config where secrets.bitwarden.enabled: true, no BWS_ACCESS_TOKEN, and an empty project_id, run hermes — the Bitwarden warning no longer prints.
2. Set a project_id (but still no token) and run hermes — the BWS_ACCESS_TOKEN is not set warning prints (actionable, partway-configured case).
3. pytest tests/test_bitwarden_secrets.py tests/test_env_loader_secret_sources.py -q — all pass (45 tests).

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass — ran the affected suites (45 passed). Note: the scripts/run_tests.sh wrapper aborts in this environment because pytest-timeout isn't installed there (unrecognized arguments: --timeout); direct pytest --timeout=60 passes.
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS (darwin-arm64)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — N/A (behavior-only change; existing docs describe the partway-configured warnings, which still fire)
• I've updated cli-config.yaml.example if I added/changed config keys — N/A (no config keys changed)
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — N/A (no process/path/signal/subprocess code; scripts/check-windows-footguns.py clean)
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

[konsisumer]

Closing — superseded by the consolidated #46641, which folds this PR's change in alongside the related work on the same issue. Reopen if that's not right.