docs(P47): presentation slide updates + HIPAA removal from all docs

Presentation changes (both Marp decks + source markdown):
1. Title slide: deck title as H1 (slightly bigger), 'Agentic Cloud Delivery
   Platform' as H3 subtitle — cleaner title hierarchy
2. DX deck: removed Local Reproducibility slide (not beneficial for DX)
3. DX deck: Safe Promotion Path slide redesigned with side-by-side layout
   for Approaches A and B (HTML table, two columns)
4. DX deck: 'an agent' → 'an AI agent' (slide 2 + Citizen Developer slide)
5. DX deck: What a Developer Does — diagram floated to the right side
6. Header simplified to just the deck name (subtitle now on title slide)

HIPAA removal (25 files):
- Completely removed all HIPAA references from all markdown documentation,
  presentation source files, module READMEs, and rendered HTML
- Removed HIPAA from compliance milestone lists (GDPR, SOX, SOC2, DORA remain)
- Removed HIPAA section references (§164.xxx) from compliance annotations
- Cleaned up empty parentheses and broken commas left by removal
- Re-rendered both HTML decks from updated Marp source

---ci---
phase: 47
milestone: v1.9
status: complete
requirements:
  covered: []
  partial: []
---/ci---

docs/presentations/the-developer-experience.md

@@ -1,7 +1,8 @@
 # The Developer Experience
 
+> **Subtitle:** Agentic Cloud Delivery Platform
 > **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
-> **Length:** ~15 minutes · 14 slides
+> **Length:** ~15 minutes · 13 slides
 > **Purpose:** Sell the developer experience and the citizen developer experience to tech leadership — velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort.
 > **Maturity framing:** "Available today" = shipped and verified. "Planned" = on the roadmap, not yet shipped.
 
@@ -22,7 +23,7 @@ flowchart TD
 ```
 
 - **Technical developer** — owns app code + a contract + a thin CI definition. Uses the full module catalog and inputs.
-- **Citizen developer** — declares intent in plain language; an agent produces a contract that passes the **same** safety envelope as a senior engineer's.
+- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope as a senior engineer's.
 
 The platform is **opinionated in what it accepts, regardless of who is declaring.** There is no "citizen developer mode" with weaker checks.
 
@@ -59,7 +60,7 @@ The developer does **not**:
 A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module.
 
 - The consumer opens an issue describing what they need (e.g. "a web API for the pricing service").
-- An agent maps the intent to a contract referencing a module from the **reviewed skill catalog.**
+- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog.**
 - The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion.
 
 **Guardrails that make this safe:**
@@ -176,20 +177,7 @@ After a successful deploy, the developer gets their connection information **wit
 
 ---
 
-## Slide 9 — Local Reproducibility
-
-The entire CI pipeline runs **from the shell**, not just in CI.
-
-- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence. Exits 0 with "CI PIPELINE OK." *(Available today.)*
-- `scripts/run_platform.sh --check-only` runs the platform offline — **no AWS, no policy engine, no outbox required.** Validates a contract end-to-end before pushing. *(Available today.)*
-- `--plan-only` runs through the infrastructure plan without applying.
-- The CI and deploy pipelines are defined by **declarative contracts** (YAML instances validated against JSON Schemas) — a single source of truth that both the GitHub and Gitea workflows implement. A test asserts conformance.
-
-> **Speaker notes:** This is the "no 'works on my machine' for CI" slide. A developer can reproduce the exact CI behavior locally before pushing. For the Head of Engineering: this shrinks the PR-cycle time because failures are caught pre-push, and it makes the pipeline itself a reviewable artifact (the YAML contract), not tribal workflow code.
-
----
-
-## Slide 10 — Friendly Onboarding
+## Slide 9 — Friendly Onboarding
 
 First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully.
 
@@ -308,7 +296,7 @@ Developers pick from **pre-built, security-reviewed building blocks** — they d
 - **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry). *(Available today.)*
 - **Validated examples per module** — every module ships `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently. *(Available today.)*
 - **Auto-promotion of patterns** — a thin-composition layer is auto-promoted to the catalog after 3 observed usages. *(Mechanism planned.)*
-- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, HIPAA, DORA controls will wire in. *(Compliance milestone is planned.)*
+- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in. *(Compliance milestone is planned.)*
 
 > **Speaker notes:** The catalog is what makes "declare intent" practical — you can only declare a module that exists. For leadership: the catalog is the leverage. One well-reviewed module serves every consumer; a fix to the module serves every consumer on the next run. This is the compounding asset.