[AZ-484] Cycle 1 Steps 12-16: docs, security, perf, deploy report

Captures the post-implementation autodev gates for AZ-484 multi-source
tile storage:

- Step 12 (Test-Spec Sync): added 7 AC rows (AZ-484 AC-1..AC-7) and a
  PT-07 NFR row to traceability-matrix.md; added PT-07 scenario to
  performance-tests.md.
- Step 13 (Update Docs): refreshed data_model.md (tiles columns +
  indexes + selection rule + UPSERT contract + migrations 012/013),
  module-layout.md (Common/Enums section with L-001 guidance,
  DataAccess imports-from now lists 6 sites), 6 module / component
  docs to reflect the new repo signatures, source/captured_at fields,
  and Dapper enum bypass workaround. ripple_log_cycle1.md records
  zero out-of-scope ripple.
- Step 14 (Security Audit): PASS_WITH_WARNINGS - 0 Critical, 0 High,
  5 Medium, 5 Low. AZ-484 itself added zero new findings. Hardening
  items (Postgres default creds, .env in build context, GMaps key
  rotation, ASP.NET Core 8.0.21 -> 8.0.25, rate limiter) recorded
  for separate tickets.
- Step 15 (Performance Test): all PT-01..PT-07 scenarios Unverified
  (non-blocking); PT-07 baseline-comparison harness deferred to a
  leftover for next cycle.
- Step 16 (Deploy): cycle deploy report covering migration safety,
  rollback path, post-deploy verification, security caveats.

Co-authored-by: Cursor <cursoragent@cursor.com>

_docs/06_metrics/perf_2026-05-11_cycle1_az484.md

@@ -0,0 +1,52 @@
+# Perf Run — Cycle 1 (post-AZ-484)
+
+**Date**: 2026-05-11
+**Mode**: `test-run` perf mode
+**Runner detected**: `scripts/run-performance-tests.sh` (PT-01..PT-06)
+**Target**: `API_URL=http://localhost:18980` (would require local docker stack)
+**Status**: **NOT EXECUTED** — see "Run decision" below
+
+## Run decision
+
+The perf gate did not execute scenarios in this cycle. The choice was made at the autodev Step 15 user-prompt with full context:
+
+- AZ-484 changed the read hot path (`GetTilesByRegionAsync` now uses `DISTINCT ON`; `GetByTileCoordinatesAsync` uses the new most-recent-across-sources tie-break).
+- The cycle-specific NFR `PT-07` (recorded in `_docs/02_document/tests/performance-tests.md` and the traceability matrix during Step 12) requires `p95 ≤ 1.10 × pre-AZ-484 baseline`. The runner script `scripts/run-performance-tests.sh` does **not yet have a PT-07 implementation** — adding the baseline-capture / comparison harness is its own work item.
+- Running PT-01..PT-06 requires bringing up `docker-compose` on the developer host. Per `meta-rule.mdc` execution-safety guidance, Docker / long-running perf operations need explicit user opt-in, which was not granted on this turn.
+
+## Scenario classification
+
+Per the test-run perf-mode rules, every scenario without measured data + threshold comparison is recorded as **Unverified**. Unverified is **not blocking**: the gate does not fail; it just surfaces the coverage gap.
+
+| Scenario | Threshold | Result |
+|----------|-----------|--------|
+| PT-01 Tile Download Latency (cold) | ≤ 30000 ms | **Unverified** |
+| PT-02 Cached Tile Retrieval Latency | ≤ 500 ms | **Unverified** |
+| PT-03 Region Processing 200m / z18 | ≤ 60000 ms (end-to-end) | **Unverified** |
+| PT-04 Region Processing 500m / z18 + stitch | ≤ 120000 ms | **Unverified** |
+| PT-05 5 Concurrent Regions | all complete in ≤ 300000 ms | **Unverified** |
+| PT-06 Route Point Interpolation Speed | ≤ 5000 ms | **Unverified** |
+| PT-07 `GetTilesByRegionAsync` p95 vs pre-AZ-484 baseline | ≤ 1.10 × baseline | **Unverified — harness not implemented** |
+
+## Why this is acceptable for this cycle
+
+- AZ-484's correctness was validated by the integration test `MostRecentAcrossSourcesSelection_AZ484_AC2` and the four other AZ-484 integration tests added in Step 11. Those tests use a temp `tiles_az484_*` table to avoid touching production data, and they exercise the same `DISTINCT ON` SQL path that PT-07 would measure.
+- The Step 11 unit + integration suite passed clean against the post-AZ-484 code; there is no functional regression to feed a perf regression.
+- The post-AZ-484 SQL is structurally cheaper or equivalent to the pre-AZ-484 path: `DISTINCT ON` over the same `(latitude, longitude, tile_zoom, tile_size_meters)` subset uses the existing `idx_tiles_unique_location_source` index. There is no new join, no new full-table scan, and no new lock surface.
+- The audit-only nature of this gap is logged so the next cycle picks it up — see leftover entry.
+
+## Follow-up work (logged as a leftover)
+
+A leftover file `_docs/_process_leftovers/2026-05-11_perf-pt07-harness.md` records the deferred work to:
+
+1. Implement PT-07 in `scripts/run-performance-tests.sh` (capture baseline, run post-change measurement, compute ratio).
+2. Re-run the full perf suite once the docker stack is available and the harness is in place.
+3. Flip PT-07 from "recorded" to "active" in `_docs/02_document/tests/performance-tests.md` and the traceability matrix.
+
+## Self-verification
+
+- [x] Runner detection executed (`scripts/run-performance-tests.sh` exists)
+- [x] Run decision recorded with reasons
+- [x] Every scenario classified (Pass / Warn / Fail / Unverified)
+- [x] Follow-up work captured as a tracker leftover (non-user-input blocker per `tracker.mdc`)
+- [x] No fabricated metrics — every "Unverified" is genuine