[harshitethic]

Why

First-run configuration entries can hide destructive infrastructure commands that the existing scanner does not yet classify as high-risk. That matters even when a command is not obviously malicious: kubectl delete namespace, Docker volume pruning, and cloud project deletion can remove critical user data when triggered automatically.

What's included

Ten new narrowly scoped high-risk patterns:

• Git force pushes (excluding --dry-run)
• Docker Compose volume teardown and Docker volume pruning (excluding help-only commands)
• Kubernetes bulk deletion and namespace deletion (excluding --dry-run)
• Helm release uninstall (excluding help-only/dry-run)
• AWS S3 recursive removal and bucket deletion (excluding dry-run/help)
• Unattended Terraform apply (-auto-approve and --auto-approve)
• Google Cloud project deletion

Every signature has a positive reproduction and a non-destructive false-positive counterexample in tests/test_extended_risks.py. The existing integration tests also verify that each command escalates through package lifecycle scanning.

Verification

• Locally executed the full pytest suite: 113 passed, 1 skipped, 183 subtests passed on Python 3.12.
• The pushed source, test, and documentation Git blob hashes match the locally verified files byte-for-byte.
• Risk rules classify static strings only; no commands in examples or tests are executed.

The commit history has 22 distinct implementation, tests, and documentation changes. Please retain the commits in the merge history for traceability.