Advisory resolution: nanoid and DOMPurify

PR #3303. Security Tests was red on main itself, not just on one PR, so every open PR inherited the failure. Toggle the state to see what changed and why a bump was the right instrument rather than an allowlist entry.

1. Before and after

WorkspacePackageVersionAdvisorySeverity

2. Why a bump, not an allowlist

Both packages are leaf nodes: nothing in either tree depends on them, and both had a non-major fix available on the day the advisory landed. An allowlist entry would have been wrong twice over. It would suppress a problem that was fixable immediately, and .claude/audit-allowlist.json entries carry an until date, so the gate would have failed again later for exactly the same reason with the fix no closer.

3. The step that was not automatic

postcss requires nanoid ^3.3.16 fixed version nanoid 3.3.18 <- already inside ^3.3.16 npm audit fix "up to date" <- left it at 3.3.16 anyway

Nothing was blocking the upgrade. npm simply does not re-plan an entry that already satisfies its declared range, so the resolved version stayed vulnerable while the range said it need not be. Adding the override alone did not move it either. The stale lock entry is dropped so npm re-resolves it, and the "nanoid<3.3.17" -> "^3.3.18" override stays to stop the next lockfile refresh from walking back to a vulnerable-but-in-range version. It sits beside the postcss@<8.5.14 entry already in that block, same pattern, same reason.