fix(security_guards): reject un-allowlisted .gitignore negations (fail-open on re-included personal data)

[thejesh23]

What changed and why

tools/security_guards.py check_gitignore() verified each required personal-data rule was present in .gitignore via set membership. But .gitignore is order-sensitive and supports negation (!pattern): a later !salary_data.json re-includes a file an earlier rule excluded. The required line is still physically present, so the guard reported OK while the file was no longer ignored — the guard failed open on exactly the weakening its docstring says it catches.

This keeps the required-rules-present check and additionally rejects any negation line not in a small reviewed allowlist, ALLOWED_IGNORE_NEGATIONS (the four benign negations the template already ships). It mirrors the existing ALLOWED_PERMISSIONS pattern: an intentional negation must be added to the allowlist in the same PR, so the widening is explicit and reviewable.

Fixes #194

Failing case / reproduction (for fixes)

On master:

$ printf '\n!salary_data.json\n' >> .gitignore
$ python3 tools/security_guards.py; echo "guard exit: $?"
security_guards: OK (permissions allowlist, gitignore rules, package manifests)
guard exit: 0
$ git check-ignore salary_data.json; echo "check-ignore exit: $?"
check-ignore exit: 1        # 1 = NOT ignored → the file will be committed

With this change the guard exits 1 on that .gitignore and names the offending negation.

The new test GitignoreNegationTests.test_negation_reincluding_personal_data_fails fails on master (guard returns 0) and passes here; test_allowlisted_negations_pass confirms the four shipped negations still pass.

Verification

• python3 tools/security_guards.py → OK (real repo's four live negations are allowlisted)
• python3 -m unittest discover -s tests -t . -v → 17 tests OK (2 new)
• python3 tools/lint_skills.py → exit 0
• python3 tools/check_framework_version.py → exit 0
• Confirmed the new test fails against the master guard (0 != 1) and passes against the patched guard.

[MadsLorentzen]

Merged - thank you, and welcome. Filing the issue and the fix together, each scoped to one concern, is exactly the shape that makes a review fast. I reproduced the fail-open and ran the guard suite locally before merging - the negation test and the benign-allowlist test both hold, and the allowlist matches the four negations the template legitimately ships today. The same-PR "add an intentional negation here, explicitly" convention mirrors how ALLOWED_PERMISSIONS already works, so it reads as native to the guard. Strong first contribution - and there's a companion PR (#199) that fixes an active leak in the same area (a rooted seen_jobs.json rule that never matches the real path); your guard hardening and that fix reinforce each other well.