背景
NexFlow 的 SHOW_MENU / MENU_CASE / END_MENU 是一組成套的流程控制動作
（顯示選單 → 各選項的分支 → 結束選單），MacroDroid 也有類似的「選項對話框」動作。
目前三個都不在 ACTION_TYPE_MAP 裡。
為什麼比其他對照難
不是 1 對 1 的關係。MacroDroid 很可能把整個選單和它的分支存成一個動作
（選項清單是那個動作的 option），而 NexFlow 是把它攤平成 SHOW_MENU + 多個
MENU_CASE + END_MENU 的線性序列。
所以這題需要在轉換時把一個 MacroDroid 動作展開成多個 NexFlow 動作，
而現在的 convertAction() 是 mapIndexed 一對一的結構（注意 order = index，
展開後 order 要重新計算）。
IF_BLOCK / ELSE_BLOCK / END_IF 已經是類似的攤平結構，可以參考它們在
MacroDroid 那邊是怎麼存的，說不定 MacroDroid 也是攤平的、那就簡單很多。
要做什麼
- 先研究：從實際的
.mdr 檔看 MacroDroid 怎麼存選項對話框，把結果貼在這串下面
- 再決定要不要／怎麼實作
光是第一步（研究並回報結構）就是有價值的貢獻，不一定要寫程式。
驗收標準
- 若實作：
MdrToFlowConverterTest 有「一個 MacroDroid 選單動作 → 正確展開成
SHOW_MENU + N 個 MENU_CASE + END_MENU、order 連續」的測試
- 若無法合理對應：把結論寫在這串，並改成讓警告訊息更明確，然後關掉這個 issue
背景
NexFlow 的
SHOW_MENU/MENU_CASE/END_MENU是一組成套的流程控制動作（顯示選單 → 各選項的分支 → 結束選單），MacroDroid 也有類似的「選項對話框」動作。
目前三個都不在
ACTION_TYPE_MAP裡。為什麼比其他對照難
不是 1 對 1 的關係。MacroDroid 很可能把整個選單和它的分支存成一個動作
（選項清單是那個動作的 option），而 NexFlow 是把它攤平成
SHOW_MENU+ 多個MENU_CASE+END_MENU的線性序列。所以這題需要在轉換時把一個 MacroDroid 動作展開成多個 NexFlow 動作，
而現在的
convertAction()是mapIndexed一對一的結構（注意order = index，展開後 order 要重新計算）。
IF_BLOCK/ELSE_BLOCK/END_IF已經是類似的攤平結構，可以參考它們在MacroDroid 那邊是怎麼存的，說不定 MacroDroid 也是攤平的、那就簡單很多。
要做什麼
.mdr檔看 MacroDroid 怎麼存選項對話框，把結果貼在這串下面光是第一步（研究並回報結構）就是有價值的貢獻，不一定要寫程式。
驗收標準
MdrToFlowConverterTest有「一個 MacroDroid 選單動作 → 正確展開成SHOW_MENU + N 個 MENU_CASE + END_MENU、order 連續」的測試