docs: add vulnerability report template and owners to SECURITY.md

[Rafiat30]

Closes #546

Summary

SECURITY.md documented a 90-day disclosure window but gave reporters no structured format to file a report in and no named contact for coordination beyond a bare email address. There was also no link to it from README.md, so someone auditing the repo for a security process had no obvious way to find it.

This adds a copy-into-your-email report template, expands SECURITY.md with scope, concrete response timelines, and a named report owner, links it from the README, and adds a CI check that keeps all three in sync going forward.

Changes

New files

• .github/SECURITY_REPORT_TEMPLATE.md — a template reporters copy into their email to security@bettapay.com. Covers: summary, affected component (checkboxes for each crate + tooling), vulnerability class, a self-assessed severity level, reproduction steps/PoC, impact, an optional suggested fix, and disclosure preferences (credit name, contact method, any deadline constraints). Opens with an HTML comment reminding reporters not to file this as a public GitHub issue/discussion/PR.
• scripts/check_security_docs.sh — verifies SECURITY.md references the template file and lists a security@ contact address, and that README.md links to SECURITY.md. Follows the existing scripts/check_wasm_size.sh pattern (sources scripts/lib/common.sh, honors a ROOT_DIR override for testability).
• scripts/tests/check_security_docs_smoke_test.sh — exercises the check script against fixture docs in a mktemp -d sandbox, following the same pattern as the existing scripts/tests/tooling_smoke_test.sh.

Modified files

• SECURITY.md — added a Scope section (which crates/tooling this policy covers, and a pointer to where frontend/backend issues should go instead); reworded the reporting section to point at the new template and to draw a clearer line between what needs a private report vs. what's fine as a normal public issue; replaced the vague "we aim to acknowledge" with three concrete commitments (48h acknowledgment, 5-business-day initial assessment, ongoing updates + credit); added a Report Owners section naming a primary security contact and what to do if you don't hear back in 48 hours.
• README.md — new Security section (after Dependencies) linking to SECURITY.md.
• Makefile — added a check_security_docs target wired into make all, and added the new smoke test to the existing test_scripts target.

No contract (Rust) source changed in this PR.

Implementation details

• Owner choice: named @therealjhay as the primary security contact — the same real, most-active contributor (237 contributions via gh api repos/Betta-Pay/BettaPay-Contract/contributors, vs. 21 for the next-highest) I used as the CODEOWNERS owner in a companion PR for No ownership/CODEOWNERS for document vs code changes #547. I deliberately did not reference .github/CODEOWNERS from SECURITY.md in this PR, since that file doesn't exist on main yet (it's introduced in the separate No ownership/CODEOWNERS for document vs code changes #547 PR) — this PR needs to stand on its own regardless of merge order.
• Kept the template as a separate file rather than inlining it in SECURITY.md, so a reporter can literally copy the whole file into an email without needing to extract a section out of a longer policy document.
• The "5 business days for an initial assessment" timeline is new — the previous text only promised acknowledgment plus "a fix timeline" with no bound on when that timeline itself would arrive. I picked 5 business days as a concrete, defensible commitment on top of the existing 48-hour acknowledgment; happy to adjust if maintainers want a different number.

Tests added

scripts/tests/check_security_docs_smoke_test.sh covers, each against a disposable fixture repo in mktemp -d:

1. A fully consistent set of docs (SECURITY.md referencing the template + a contact address, README linking to SECURITY.md) passes.
2. A missing template file fails.
3. SECURITY.md not referencing the template fails.
4. SECURITY.md missing a security@ contact address fails.
5. A README with no SECURITY.md link fails.

I also manually ran bash scripts/check_security_docs.sh against this PR's real docs (passes) before finalizing the smoke test.

How to test

# The new check against this PR's real docs
make check_security_docs
# or directly:
bash scripts/check_security_docs.sh

# The new smoke test (also runs as part of `make test_scripts`)
bash scripts/tests/check_security_docs_smoke_test.sh

# Full contributor gate, including both of the above
cargo build --target wasm32-unknown-unknown --release
make all

# Full workspace test suite (no Rust source changed in this PR, included per the issue's acceptance criteria)
cargo test --workspace

[drips-wave]

@Rafiat30 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits