chore(security): add Dependabot config

[jml6m]

Part of the org-wide repo security audit.

This repo has no package.json (front-end assets are loaded via CDN), so the npm ecosystem block is intentionally commented out as a template for future use. Only github-actions is active today, which will keep any future workflow Action versions patched automatically.

[Copilot]

Pull request overview

Adds a Dependabot configuration as part of the org-wide security audit, enabling automated dependency update PRs for GitHub Actions while leaving a commented npm template for a potential future migration to a bundled/npm-managed frontend.

Changes:

• Add .github/dependabot.yml with weekly checks for the github-actions ecosystem.
• Configure Dependabot PR metadata (commit message prefix/scope) and include a commented-out npm configuration template for future use.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jml6m]

@copilot why does it say:

Merging is blocked
Commits must have verified signatures.

[Copilot]

@copilot why does it say:

...

Because the PR is targeting the protected master branch, and that branch appears to require verified commit signatures. That check is about GitHub-recognized GPG/SSH/S/MIME signatures on the commits in the PR—not the Signed-off-by: line in a commit message. So if even one commit in this PR isn’t cryptographically verified by GitHub, merge gets blocked.

[jml6m]

@copilot Yes but If I'm having you do PRs and changing the code on those PRs...why aren't you following the repo rules? Or is some setting misconfigured?

[Copilot]

@copilot Yes but If I'm having you do PRs and changing the code on those PRs...why aren't you following the repo rules? Or is some setting misconfigured?

It looks more like a limitation of the commit path than a bad repo rule. The branch rule is working as configured, but the original PR commit (55aa078) appears to have been created without a GitHub-verifiable GPG/SSH/S/MIME signature, so it doesn’t satisfy “verified signatures required.” The later web-flow suggestion commit does show a cryptographic signature. So the mismatch is: I was able to create/update the PR, but that path didn’t guarantee a verified-signed commit. To satisfy the rule, the unsigned commit would need to be recreated with a verified signing key (or the rule/exemptions adjusted for this workflow).