docs(security): add Data Privacy & Compliance section to security-and-hardening

[HMAKT99]

What and why

security-and-hardening already owns the answer to "can an attacker read this data?" This PR adds the companion question agents currently have no guidance on: "should we even hold this data, and for how long?" — a separate concern that hardening alone doesn't answer.

Addy's closing note on #347 was: "Data privacy and compliance fit security-and-hardening rather than a separate section; closing here, a focused addition to that skill would be welcome." This is that addition.

Why it belongs in security-and-hardening

• The skill already tells agents to protect PII in logs (Step 3: Structured Logging cross-reference), encrypt sensitive fields, and exclude them from API responses. The natural next question is: which fields are PII, what makes something sensitive, and what happens when a user asks you to delete it? Those answers belong in the same place.
• The security skill's existing Verification checklist already checks PII encrypted at rest — this PR gives agents the classification framework they need to answer that checkbox correctly.
• No new skill directory needed; no new routing surface introduced. Frontmatter description is unchanged.

Content (+33 lines, one file)

A new ## Data Privacy & Compliance section covering four actionable decisions:

1. Classify fields as you add them — PII classification table (non-personal / personal PII / sensitive) with handling rules per class. Agents can't protect or delete what they haven't classified.

2. Four operating rules — minimize and state a purpose before collecting; set retention up front and build a working deletion path (including backups, caches, indexes); support data-subject rights (export, correct, delete) by designing the schema to be findable and erasable; get auditable consent before sharing PII with third parties or vendors.

3. Cross-references without duplication — points to observability-and-instrumentation for the "never log PII" rule (already there), and to debugging-and-error-recovery for breach-notification timing in postmortems. No content duplicated.

4. Three Verification checkboxes added to the existing checklist:

• Personal data classified, collected against a stated purpose, minimized
• Retention limit and working deletion path (including backups/indexes)
• Export/delete requests supported; third-party sharing has consent

Also adds three rationalization rows and three red flags to the existing sections.

What this is not

This is not a GDPR compliance guide. It's the minimum a coding agent needs to avoid building systems that fail deletion requests, send PII to analytics vendors without consent, or collect fields with no stated purpose. Legal detail belongs elsewhere; engineering decisions belong here.

Validator: 0 errors, 0 warnings. One file. Frontmatter description unchanged (no routing surface added).

[addyosmani]

This is the right home for it, thanks for moving it into security-and-hardening after the earlier round. The data classification plus operating rules reads well and it's in scope here. Approving.