Add CI to mimic qgis repo checks

[harminius]

Summary

Makes CI reproduce the security and style scan that plugins.qgis.org runs on every upload, so we find out about a blocking finding on push instead of at release time.

We already had a security_check.yml, but it did not reflect what the repository actually runs and could not fail on the things that matter:

• detect-secrets scan always exits 0, including on files containing valid-format AWS keys and GitHub tokens. That step could never fail the build.
• Bandit ran with -ll rather than the repository's explicit test list, so it silently skipped checks qgis.org treats as blocking - hardcoded passwords (B105–B107) among them.
• Flake8 ran its full default rule set and picked up our pyproject.toml. The repository enables only 26 of 96 codes and never sees that file, so the local result and the upstream result were unrelated.

How the upstream gate actually works

Check	Severity	Effect on upload
Bandit	critical	any finding → version BLOCKED
detect-secrets	critical	any finding → BLOCKED
Flake8	info	reported on the plugin page, never blocks
File analysis	warning / info	reported, never blocks

Rules the administrators mark skippable still block unless the uploader ticks them on the upload form; mandatory rules cannot be waived at all.

What this adds

• scripts/qgis_plugin_repo_rules.json — a pinned snapshot of all 205 rules from qgis/QGIS-Plugins-Website
• scripts/qgis_plugin_repo_checks.py — runs the three tools with the same flags and rule selection the repository uses, classifies each finding as mandatory or skippable, and exits non-zero only on blocking mandatory findings.
• .github/workflows/security_check.yml — rewritten to call the script, with tool versions pinned

Scan scope mirrors the rsync filter in packages.yml (test/, __pycache__/ excluded), so we check what actually ships rather than what happens to be in the tree.

Resolves https://github.com/MerginMaps/server-private/issues/3512