feat: add security-first enforcement layer with threat-model-anchored verification

Adds /gsd:secure-phase command and gsd-security-auditor agent as a
threat-model-anchored security gate parallel to Nyquist validation.

New files:
- agents/gsd-security-auditor.md — verifies PLAN.md threat mitigations
  exist in implemented code; SECURED/OPEN_THREATS/ESCALATE returns
- commands/gsd/secure-phase.md — retroactive command, mirrors validate-phase
- get-shit-done/workflows/secure-phase.md — enforcing gate: threats_open > 0
  blocks phase advancement; accepted risks log prevents resurface
- get-shit-done/templates/SECURITY.md — per-phase threat register artifact

Modified:
- config.json — security_enforcement (absent=enabled), security_asvs_level,
  security_block_on parallel to nyquist_validation pattern
- VALIDATION.md — Threat Ref + Secure Behavior columns in verification map
- gsd-planner.md — <threat_model> block in PLAN.md format + quality gate
- gsd-executor.md — Rule 2 threat model reference + ## Threat Flags scan
- gsd-phase-researcher.md — ## Security Domain mandatory research section
- plan-phase.md — step 5.55 Security Threat Model Gate
- execute-phase.md — security gate announcement in aggregate step
- verify-work.md — /gsd:secure-phase surfaced in completion routing

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

agents/gsd-executor.md

@@ -133,6 +133,8 @@ No user permission needed for Rules 1-3.
 
 **Critical = required for correct/secure/performant operation.** These aren't "features" — they're correctness requirements.
 
+**Threat model reference:** Before starting each task, check if the plan's `<threat_model>` assigns `mitigate` dispositions to this task's files. Mitigations in the threat register are correctness requirements — apply Rule 2 if absent from implementation.
+
 ---
 
 **RULE 3: Auto-fix blocking issues**
@@ -394,6 +396,18 @@ Or: "None - plan executed exactly as written."
 - Components with no data source wired (props always receiving empty/mock data)
 
 If any stubs exist, add a `## Known Stubs` section to the SUMMARY listing each stub with its file, line, and reason. These are tracked for the verifier to catch. Do NOT mark a plan as complete if stubs exist that prevent the plan's goal from being achieved — either wire the data or document in the plan why the stub is intentional and which future plan will resolve it.
+
+**Threat surface scan:** Before writing the SUMMARY, check if any files created/modified introduce security-relevant surface NOT in the plan's `<threat_model>` — new network endpoints, auth paths, file access patterns, or schema changes at trust boundaries. If found, add:
+
+```markdown
+## Threat Flags
+
+| Flag | File | Description |
+|------|------|-------------|
+| threat_flag: {type} | {file} | {new surface description} |
+```
+
+Omit section if nothing found.
 </summary_creation>
 
 <self_check>