Initial commit: Imperva WAF demo lab

Flight-booking app scaffolded from the source running on the GCP host,
plus the four-screen frontend and three OWASP attack endpoints (SQLi,
reflected XSS, path traversal) built and locally verified against a
live uvicorn/vite dev pair. Includes deploy.sh (local build -> ship
over ssh -> swap on host) and docs/ carried over from the handoff.

docs/DEMO_RUNBOOK.md

@@ -0,0 +1,61 @@
+# Demo Runbook
+
+> **Status: BUILT, not yet deployed to the GCP host.** All four screens and three
+> attack endpoints exist in `backend/` and `frontend/` and were functionally verified
+> locally (backend via `uvicorn` + `curl`, frontend via `vite dev` + a browser, talking
+> to each other through the same `/api/*` path Caddy proxies in prod — including
+> confirming the XSS payload actually executes and the traversal payload actually reads
+> a file outside `boarding_passes/`). Not yet shipped with `./deploy.sh` — that must run
+> from a real host terminal, not an AI coding-agent sandbox (see CLAUDE.md).
+
+Goal of the demo: type an attack into a believable flight-booking UI, watch Imperva
+block it, then show the corresponding event in the Imperva portal. Three attacks, three
+*distinct* portal classifications.
+
+## Attack matrix
+
+| # | Attack          | Endpoint                    | Sample payload                     | Expected Imperva portal classification         |
+|---|-----------------|-----------------------------|------------------------------------|------------------------------------------------|
+| 1 | SQL Injection   | `/api/v1/users?q=`          | `' OR '1'='1`                      | SQL Injection                                  |
+| 2 | Reflected XSS   | `/api/v1/search?term=`      | `<script>alert(1)</script>`        | Cross-Site Scripting (XSS)                     |
+| 3 | Path Traversal  | `/api/v1/download?file=`    | `../../../../etc/passwd`           | Illegal Resource Access / Directory Traversal  |
+| — | (bonus) Cred stuffing | `/api/v1/login`       | repeated login attempts            | Requires a **custom rate policy**, not a signature — not in core demo |
+
+Attacks 1–3 are blocked by Imperva's **default signatures** — no custom rules needed.
+The bonus is intentionally excluded from the core demo because it needs a rate policy
+configured in Imperva and doesn't produce a clean single-payload block (see
+DECISIONS.md D7).
+
+## Frontend screen → attack mapping
+
+Each attack has a natural home in the UI so the demo looks like poking a real product:
+
+- **Passenger / admin lookup** → SQLi search box (`users?q=`)
+- **Flight search results** → XSS search field (`search?term=`)
+- **Boarding-pass download** → path-traversal file param (`download?file=`)
+- **Login** → existing endpoint, kept as the credential-stuffing bonus
+
+## Demo flow (target)
+
+1. Show the app working normally (a legitimate search, a legitimate lookup).
+2. For each of the three attacks: enter the payload in its screen → show the request is
+   blocked by Imperva (block page / rejected response).
+3. Switch to the Imperva portal security dashboard → show the three distinct event
+   types logged, one per attack.
+4. Reinforce the isolation point: the origin only accepts Imperva CIDRs, so these
+   attacks *cannot* reach the app except through the WAF — which is why every one of
+   them appears in the portal.
+
+## Pre-demo checklist
+
+- `https://flytoouter.space/` loads with Imperva's trusted edge cert.
+- All three endpoints reachable *through* Imperva (legit requests return 200).
+- Origin firewall confirmed Imperva-CIDR-only (`allow-imperva-waf`, `tcp:443`).
+- DNS for `flytoouter.space` points at Imperva, not the raw origin IP.
+- Portal logged-in and on the security events view, filtered to the demo site.
+
+## Notes on portal specifics
+
+Exact event labels and menu paths vary by Imperva account/version. Confirm the live
+labels in your portal before presenting and update the classification column above to
+match what your account actually shows.