Register the three required security-scan check contexts in branch protection (#1132 follow-up)

[Chris0Jeky]

PR #1170 added secret-scan, dependency-security, and sast-scan jobs to ci-required.yml as enforcing gates. Because ci-required.yml has no aggregation gate job, each runs as an independent check and is not merge-blocking until its context is added to the protected-branch required-status-checks list (a repo-settings action, not doable from PR code).

Action (maintainer)

Add these exact check contexts (<caller job> / <inner job>) to branch protection on main:

• Secret Scan / Gitleaks Scan
• Dependency Security / Dependency Security Signals
• SAST Scan / SAST Scan (Semgrep)

(The bundle-size check rides inside the already-required Frontend Unit job — no separate context.)

Until then the scans run red/green advisory-style but PRs can still merge. Source: adversarial review of #1170. See ADR-0035.

[Chris0Jeky]

merge_group consideration (from #1170 Codex review): the secret-scan job is guarded to pull_request events because gitleaks PR scan-mode is invalid on push/merge_group. On merge_group it is skipped (neutral check). When registering the required check contexts, either (a) do not require Secret Scan / Gitleaks Scan in the merge queue, or (b) confirm GitHub treats the neutral skip as passing for the queue. The other scans (Dependency Security, SAST Scan) run on all events.