docs(04-04): /cari menu diagnosis — non-default setMyCommands scopes silently no-op (Telegram-side)

.planning/phases/04-destination-search-kl-gazetteer/04-DEVICE-GATE.md

@@ -150,3 +150,28 @@ real client proves Telegram actually delivers the button's query string into the
 
 *Phase: 04-destination-search-kl-gazetteer — plan 04-04 blocking gate*
 *Automated legs + deploy: 2026-10-23; physical legs: pending user*
+
+## Post-gate findings (2026-10-24, continued)
+
+**Legs 1–4 + 6 PASS; leg 5 FAIL (BotFather Main Mini App — user completing).**
+
+### /cari missing from the command menu — diagnosis chain
+
+1. Commands ARE registered in default + ms scope via API (`getMyCommands` proves it).
+2. A STALE `all_private_chats` set (phase-2 era: help/privacy only) exists server-side
+   and SHADOWS default (Telegram resolves a chat's menu from the narrowest scope with
+   any commands).
+3. Attempted fixes: re-armed `all_private_chats` (en+ms), cleared junk group scopes,
+   armed the user's `chat` scope directly — **every non-default `setMyCommands` write
+   returns ok:true but stores nothing** (control: default-scope canary write lands fine;
+   canary reads on all_private_chats/chat scopes unchanged across 100s+).
+4. `register-commands.mjs` rewritten to arm/clear ALL scopes durably (commit `54a2b54`)
+   + gates updated (CS5/CR13: single fetch site, shadow law pinned).
+
+**Status: Telegram-side silent-write defect on non-default scopes.** Two outcomes:
+- If the user's client NOW shows /cari after refresh → the writes landed server-side
+  and only `getMyCommands` reads are cached — done.
+- If still help/privacy → the stale set is unreachable by API; retry the register
+  script later (`node bot/scripts/register-commands.mjs`) — non-default writes worked
+  for this same token in phase 2, so this is plausibly a transient DC defect, and
+  default scope + client cache may also simply recover it.