staging has no branch protection — CI security gates run but don't block merges

[jgruberf5]

Summary

staging — the integration branch every release is promoted from — has no branch protection at all:

$ gh api repos/f5devcentral/bnk-forge/branches/staging/protection
{"message":"Branch not protected","status":"404"}

So the CI jobs, including the new gitleaks / shellcheck / version-consistency security gates (#182, #180), run but are not required checks. Nothing blocks a merge to staging when a gate is red — a secret, a shellcheck failure, or a version-drift could land and then be promoted.

Found in a pre-4.0.0-release critical review, alongside #184.

Why it matters

• The whole point of wiring gitleaks/shellcheck into CI (Wire gitleaks / shellcheck / script self-test CI gates — PR #177 Major #182) is to gate. Without a required-check config, they're advisory only.
• It also explains the observation on PR Release workflow: republish recovery path + RC/loop-guard robustness — PR #177 Blocker 3 #181 that a release-workflow-only PR reported no CI checks at all — there are no required contexts on the branch.
• Asymmetry: main is protected to the point the release automation itself can't push (lock_branch: true — see the release-lock discussion), while staging is wide open. Both ends want squaring before a public release leans on these gates.

Suggested fix (repo-admin, not a code PR)

• Add branch protection to staging requiring the aggregate CI Gate status check (and a review, matching main's intent).
• Reconcile main's lock so the release automation can complete (tracked separately with the release-lock work).
• Confirm the new P1 gates (Secret Scan, ShellCheck, Version Consistency, Script Self-Tests) are included in the required set once they've merged.

Scope

Governance/config, not code — hence no code PR. Severity medium: active human review is the current backstop (workaround exists), but the automated security gate is not actually enforcing.