repo-config/configure.sh: let check_security surface gh's error (drop 2>/dev/null)

[ptr727]

Defect

In repo-config/configure.sh, check_security() suppresses gh's stderr on the automated-security-fixes call:

assert "Dependabot automated security updates enabled" \
  jq_has '.enabled == true' < <(gh api "repos/$REPO/automated-security-fixes" 2>/dev/null)

The 2>/dev/null hides gh's diagnostic if the call fails on auth/permissions or a transient error, making a drift-check failure hard to diagnose.

Why

A prior 5D-audit hardening pass removed 2>/dev/null from check_secrets and ruleset_id so a real API/auth error prints gh's own error and FAILs loudly (distinct from a genuinely-missing/false config). check_security was missed in that pass.

Fix

Drop the 2>/dev/null on the automated-security-fixes call. The assert still fails correctly when security updates are genuinely disabled (the endpoint returns {"enabled": false} with HTTP 200, so jq_has '.enabled == true' is false); only a real API/auth error now shows gh's diagnostic instead of being swallowed.

Fleet consistency

repo-config/configure.sh is meant to be byte-identical across the ptr727 repos. Apply the same one-line change to every repo that carries it - LanguageTags, Utilities, PlexCleaner, VSCode-Server-DotNetCore, ESPHome-NonRoot, HomeAssistant-PurpleAir (and use the hardened form when NxWitness's repo-config is created) - so they stay identical.

Low-risk: the endpoint is always-200 {enabled: bool}. Flagged by Copilot on HomeAssistant-PurpleAir PR #158.

[ptr727]

Fixed and on main: dropped 2>/dev/null from the automated-security-fixes read in check_security so gh's error surfaces (matching the check_secrets hardening). Landed via the develop->main promotion.