docs(03-04): log debug round 2 — LocationManager openSettings deep-link round

.planning/phases/03-mini-app-shell-geolocation/03-DEVICE-MATRIX.md

@@ -124,3 +124,32 @@ re-renders the denied card — session can never validate without initData there
 the pass condition for leg 5 is the deliberate denied state itself. If Android
 still shows dead/absent retry interplay after OS location is enabled, open a
 follow-up.
+
+## 2026-10-23 debug round 2 (no prompt / no on-device enable path)
+
+**Symptom (legs 1 + 5):** denied card shows but no native prompt ever appears,
+and the card offers no way to actually enable location — TRY AGAIN instant
+re-fails when access was previously denied/services off.
+
+**Root cause:** the D-06 card only offered chain re-run + chat fallback. When
+Telegram's LocationManager has a settings-resolvable denial (access denied
+earlier, or services off), the ONLY realistic recovery is Telegram's own
+permission pane — `LocationManager.openSettings()` — which was typed optional
+but never invoked anywhere.
+
+**Fix (commit after round 1, deploy `bb92dbeb`):**
+- Denied cards gain a THIRD CTA — `LOCATION SETTINGS / TETAPAN LOKASI`
+  (new strings key pair; COPY5 gates still green) — rendered on
+  Telegram clients only (`wa.LocationManager` presence test).
+- Click → `lm.openSettings()` (gateway re-runs the chain too, covering
+  clients without the API).
+- `locationManagerUpdated` event listener re-runs the chain the moment
+  the user grants, instead of waiting for another tap.
+- UI-SPEC amendment: copy table + denied-CTA list append this third action
+  (Telegram-only conditional); rationale recorded here per debug-round
+  protocol.
+
+**Re-test instruction:** restart the Telegram client (menu is cached), open
+the app from the menu button, on the denied card tap LOCATION SETTINGS →
+grant location in Telegram's pane → the app should reach LIVE without
+another tap. Legs 1/2/6 resume from there.