Update autodev state and lessons documentation

- Changed current step from 15 (Performance Test) to 9 (New Task) in _docs/_autodev_state.md, reflecting the transition to Cycle 3.
- Updated cycle count from 2 to 3 and modified sub-step details to indicate progress in gathering feature descriptions.
- Added new lessons to _docs/LESSONS.md, emphasizing best practices for API key management, dependency handling, and reporting inline fixes during security audits.
- Enhanced CI/CD pipeline documentation in _docs/02_document/deployment/ci_cd_pipeline.md to include new gates for vulnerability scans and SBOM emissions, along with dependency overrides for transitive dependencies.
- Expanded environment strategy documentation in _docs/02_document/deployment/environment_strategy.md to include the new Google Geocode API key management.

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

_docs/_process_leftovers/2026-05-12_az-498-deploy-and-key-revocations.md

@@ -0,0 +1,99 @@
+# Cycle 2 Step 16 — Deferred deploy + manual revocations
+
+**Created**: 2026-05-12T01:44:00Z (autodev Step 16, planning-only outcome)
+**Cycle**: 2
+
+This file tracks deploy-related work that could not complete this cycle because each
+item depends on action outside this workspace.
+
+---
+
+## L-AZ-498-DEPLOY — UI tile-swap prod cutover (cross-workspace gate)
+
+**What is blocked**: prod deploy of the UI changes from cycle 2 batch 11 that route
+the map's `<TileLayer>` through the suite's own `satellite-provider` (`/tiles/{z}/{x}/{y}`)
+with same-origin cookie auth. The image will build cleanly today (the source change is in
+`dev`), but cutting prod traffic over before satellite-provider's auth migration lands
+will break the map for all users.
+
+**Cross-workspace prerequisite**: a separate AZAION ticket on the **satellite-provider**
+workspace must publish a cookie-auth variant of `GET /tiles/{z}/{x}/{y}` AND deploy that
+change to all environments the UI is promoted into (dev / stage / prod). Today the UI
+sets `crossOrigin="use-credentials"` on tile images, but the server still expects an
+`Authorization: Bearer ...` header (which Leaflet `<img>` requests cannot send).
+
+**Replay procedure** (run at the start of the next cycle's Step 16, or sooner on user
+request):
+
+1. Verify the satellite-provider workspace has merged the cookie-auth change to dev,
+   stage, and main equivalents.
+2. Verify the satellite-provider deploys are live in each environment (smoke check:
+   `curl --cookie ... https://<host>/tiles/0/0/0` returns 200 with `Content-Type: image/jpeg`).
+3. Run the UI tile-render smoke check: `bunx playwright test e2e/tests/infrastructure.e2e.ts -g "tile"`
+   against each environment.
+4. Build + push the UI image (the Woodpecker pipeline already does this on every `dev`
+   push; cycle 2 commit `f7dd6c9` is on `dev` as of 2026-05-12).
+5. Promote: `dev → stage → main` per the standard branch model
+   (`_docs/02_document/deployment/ci_cd_pipeline.md` §1).
+6. Post-deploy verification: load `/flights` on each environment, pan the map, watch
+   network panel — every `/tiles/...` request returns 200 and the request is sent with
+   the auth cookie attached.
+
+**Escalation**: if the satellite-provider ticket is still not landed by the next cycle's
+Step 16 review, surface to the user via Choose A/B/C/D — the gate cannot be silently
+bypassed because doing so produces a visibly broken map in production.
+
+---
+
+## L-AZ-499-OWM-REVOKE — OpenWeatherMap key revocation
+
+**What is blocked**: closing AZ-499 acceptance criterion AC-7 (and the equivalent
+project-wide AC-42), which requires the OWM key `335799082893fad97fa36118b131f919`
+that was previously committed to the repo to be revoked at the OWM dashboard.
+
+**Why this can't be done from this workspace**: revocation requires authenticated
+access to `https://home.openweathermap.org/api_keys` — a third-party UI that cannot
+be automated from CI without storing OWM credentials, which is out of scope.
+
+**Replay procedure** (manual, requires user):
+
+1. Sign into `https://home.openweathermap.org/api_keys`.
+2. Locate the key `335799082893fad97fa36118b131f919`.
+3. Disable / regenerate / delete it. Capture evidence: dashboard screenshot OR a
+   timestamped URL showing the key is no longer active.
+4. Attach the evidence to Jira ticket **AZ-499** (or to the parent epic if the user
+   prefers).
+5. Transition AZ-499 to **Done** in Jira.
+6. Delete this leftover entry once steps 1–5 are complete.
+
+**Compensating control already in place**: `STC-SEC1C` (in `scripts/check-banned-deps.mjs`
++ `tests/security/banned-deps.json`) prevents the literal value from re-entering the
+source tree.
+
+---
+
+## L-AZ-501-GOOGLE-REVOKE — Google Geocode key revocation
+
+**What is blocked**: closing AZ-501 acceptance criterion AC-6 (and the project-wide
+AC-43), which requires the Google Geocode key `AIzaSyAhvDeYukuyWVrQYbRhuv91bsi_jj5_Iys`
+that was previously committed in `mission-planner/src/config.ts` to be revoked at the
+Google Cloud Console.
+
+**Why this can't be done from this workspace**: same reason as AZ-499 — revocation
+requires authenticated access to `https://console.cloud.google.com/google/maps-apis/credentials`,
+which cannot be automated.
+
+**Replay procedure** (manual, requires user):
+
+1. Sign into `https://console.cloud.google.com/google/maps-apis/credentials`.
+2. Locate the key `AIzaSyAhvDeYukuyWVrQYbRhuv91bsi_jj5_Iys`.
+3. Restrict the key to no APIs / no referrers (effectively revoke) OR regenerate it.
+   Capture evidence: dashboard screenshot OR a timestamped URL showing the
+   restriction.
+4. Attach the evidence to Jira ticket **AZ-501**.
+5. Transition AZ-501 to **Done** in Jira.
+6. Delete this leftover entry once steps 1–5 are complete.
+
+**Compensating control already in place**: `STC-SEC1D` (registered in `scripts/run-tests.sh`
+under `run_static`, with the literal in `tests/security/banned-deps.json` →
+`google_key_in_source`) prevents the literal value from re-entering the source tree.