Add automated /security-review workflow for security-sensitive PRs

Summary

Wire up an AI-assisted security review (/security-review via the Anthropic Claude Code GitHub Action) to run automatically on every PR that touches a security-sensitive path. Purely human review can miss issues. An automated reviewer running on each PR is a force-multiplier for the security team.

What this enables

• A security review runs automatically on every PR touching backend Java, REST resources, auth/login code, push-publish code, OSGi, SQL, build files, Dockerfiles, or workflows.
• If high-confidence findings are detected:
  • The PR gets an intentionally abstract comment (no vuln details — the repo is public).
  • The PR author is DM'd on Slack with full report and remediation guidance.
  • The check fails, blocking merge once the branch protection rule is updated.
• If no findings: the PR comment confirms a clean review.

Scope

• Land the workflow YAML (PR linked below).
• Configure repository secrets and variables (see PR description).
• Set up a Slack app/bot with chat:write, invite to the chosen private channel, store token as SLACK_BOT_TOKEN.
• Build the SLACK_USER_MAP JSON for GitHub login → Slack user ID.
• Choose the private Slack channel ID, store as repo variable SLACK_SECURITY_CHANNEL.
• Run on a few real PRs in shadow mode (not yet required) to calibrate noise and tune path filters.
• Add this check to main branch-protection's required status checks to block merge.
• Decide policy for PRs from external forks (current workflow uses pull_request, so secrets are not exposed to fork PRs — but the review also won't run for them; needs a follow-up).

Open questions

1. Which Slack channel should host the security DMs? (Private to security + R&D leadership preferred.)
2. Cost cap? Each run is non-trivial; should we throttle by path, label, or PR author group?
3. External-fork PRs: skip, run a read-only variant via pull_request_target, or handle out-of-band?
4. Should we also create a tracking issue per finding (private) for follow-up, or rely on Slack thread only?

Acceptance criteria

• Workflow file merged.
• Required secrets/variables configured.
• Branch protection updated to require the check.
• At least one PR observed running end-to-end (post-comment + Slack DM + failing check, then green after fix).