fix(skills): honor policy table for dangerous verdicts

[stablegenius49]

What does this PR do?

Fixes the skills guard install-policy precedence bug so the INSTALL_POLICY table actually controls dangerous verdict handling:

• official / builtin skills now honor the builtin policy row instead of being hard-blocked before policy lookup
• --force now overrides blocked policy decisions for trusted and community sources, including dangerous verdicts
• /skills install now accepts --yes / -y as an alias for --force
• updates the regression tests to cover the intended dangerous-verdict behavior

Related Issue

Fixes #1006

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

• tools/skills_guard.py
  • removed the hard early return that blocked all dangerous verdicts before trust-policy evaluation
  • let INSTALL_POLICY decide first, then let --force override blocked decisions
  • updated the docstring/reason text to match the new behavior
• hermes_cli/skills_hub.py
  • parse --yes / -y as aliases for --force in /skills install
  • updated slash-command usage text
• hermes_cli/main.py
  • updated CLI help text for --force
• tests/tools/test_skills_guard.py
  • added coverage for official/builtin dangerous installs and forced dangerous installs for trusted/community sources
• tests/tools/test_force_dangerous_override.py
  • rewrote the regression helper tests to reflect the intended policy-table precedence

How to Test

1. Reproduce the issue from Skills Guard: Official/builtin skills blocked by scan + --force flag doesn't override DANGEROUS verdict #1006 with an official optional skill that scans as dangerous (for example official/email/agentmail) and confirm it is no longer blocked solely by the early return.
2. Verify that a trusted or community skill with a blocked dangerous verdict is still blocked without --force, but installs when --force is provided.
3. Verify /skills install ... --yes behaves the same as /skills install ... --force.

Verification run in this environment

• ✅ python3 -m py_compile hermes_cli/main.py hermes_cli/skills_hub.py tools/skills_guard.py tests/tools/test_skills_guard.py tests/tools/test_force_dangerous_override.py
• ✅ targeted importlib-based behavior checks for:
  • official/... -> builtin
  • builtin dangerous allowed by policy
  • trusted dangerous blocked without force
  • trusted/community dangerous allowed with force
  • /skills install ... --yes setting force=True
• ⚠️ I could not run the repo's normal pytest invocation on this host because the local environment is missing project dependencies / dev tooling (rich, firecrawl, uv), so I left the full-suite checkbox unchecked instead of claiming otherwise.

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
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 15 / Python 3.9 host tooling

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A