Add a script to verify the open security PRs against a deployment

[setusher]

Summary

Adds scripts/test/pr_verification.sh, which checks fourteen of the sixteen open security PRs against a running deployment over HTTP, one section per PR, plus a self-test that proves it still reports a deployment that has the problem.

Issue

Every PR in the wave now has unit tests in CI, but all of them check a file - a permission declaration, a config fragment, a compose definition, a dependency pin. None checks a deployment that has actually been restarted.

That gap is precisely where a merged fix and a still-vulnerable server look identical:

• an image that was not rebuilt, so the container still runs the old permission classes
• a stack that was not recreated, so a removed service is still listening
• an NGINX that was not reloaded, so the old header is still being served

Green CI, vulnerable server, and nothing in the repository can tell the difference. test_auth_security.sh in omniport-backend covers the previous wave this way; this is the equivalent for the current one.

Steps to reproduce the bug/issue

Tooling rather than a defect, so there is no bug to reproduce - but the gap is reproducible:

1. Merge omniport-app-noticeboard#27 and let its CI pass. The permission declarations are correct in the repository.
2. Do not rebuild the Django image.
3. curl https://<host>/api/noticeboard/new/ with no session still returns 200 and every notice.

Nothing in any repository can distinguish that state from a correct deploy.

Steps done to fix it and test added for the same

The script. One section per PR, named after it:

groups-8  noticeboard-26  people-search-13  lost-and-found-7  registration-2
gif-3  pseudoc-1  backend-227  formula-one-19  backend-228  lectures-25
filemanager-80  maintainer-site-15  backend-226

./scripts/test/pr_verification.sh https://staging.example                     # everything
./scripts/test/pr_verification.sh https://staging.example maintainer-site-15  # one PR
./scripts/test/pr_verification.sh https://staging.example list                # section names

Routes were read, not guessed. Every path comes from the relevant repository's http_urls.py and config.yml. This matters more than it sounds - registration declares create_session and set_pass without trailing slashes, so a guessed slash produces a 404 that reads exactly like a broken allow-list.

Three sections do more than compare a status code:

• maintainer-site-15 asserts an anonymous OPTIONS still returns an actions block. SimpleMetadata.determine_actions clones the request as PUT/POST and runs check_permissions; a permission that denies anonymous writes makes DRF drop the key entirely, and team-page.js, alumni-page.js and team-individual-view.js all dereference options.actions.POST in render() with no guard. That is a white-screened public site, and it is invisible to a status-code check.
• lost-and-found-7 reads the list payload and looks for any row whose contactVisible is false but which still carries an emailAddress or primaryPhoneNumber - the exact shape of the original leak.
• filemanager-80 calls get_root with a session. That is the check that answers whether the R Drive concern blocking that PR is real against this data, rather than in principle.

A 5xx is a distinct failure class, not just "wrong code". Several of these findings fail closed - the non-object JSON body in the groups permission class, the bare except in the filemanager - so collapsing a 500 into "not 403" would hide them.

Two PRs are deliberately not covered. gym-pravesh#12 and marketplace#6 live in repositories that are not readable with the account this was written against, so their routes and permissions could not be established. Inventing checks for them would produce something that looks authoritative and verifies nothing.

Test. tests/test_pr_verification_script.py runs the real script against tests/fixtures/mock_pr_deployment.py in both configurations:

test group	asserts
TestTheScriptIsRunnable	executable, passes bash -n, every listed section has a function, unknown sections refused
TestItRunsWithoutShellErrors	every section executes; no command not found, unary operator expected, unbound variable - things bash -n cannot see inside a function
TestItReportsAVulnerableDeployment	the open faculty write routes, leaked visibility arrays, live getItem, contact details behind a false flag, dropped OPTIONS actions, anonymous user mutation
TestItPassesTheClosedChecksWhenFixed	clean sections pass; a missing session is a warning, not a pass

Measured across the two configurations:

	Failures
Fixed	8
Vulnerable	25

15 tests, all passing.

CI. .github/workflows/pr-verification-tests.yml runs the self-test on every push and pull request. It is a separate workflow and fixture filename from #58, #59 and #60, so none of these conflict.

scripts/README.md gains an entry alongside the existing scripts.

Criteria for issue to be resolved

• CI passes on this branch
• bash -n scripts/test/pr_verification.sh is clean
• ./scripts/test/pr_verification.sh <url> list prints all fourteen sections
• Running a single section runs only that section
• Against a deployment with a given PR applied, that PR's section exits 0
• Against a deployment without it, that section fails and names the defect
• Without SESSION_COOKIE, authenticated checks are reported as warnings rather than passes
• gym-pravesh#12 and marketplace#6 are documented as uncovered rather than silently missing

Note on the two gaps

If read access to omniport-app-gym-pravesh and omniport-app-marketplace is granted, both sections can be added - marketplace#6 in particular, since the non-object JSON body defect it fixes is the same one the groups-8 section already probes for.