fix(ttl): add sendlnretry — resend until the device confirms it ran the command

A device that is still booting can silently discard console input the moment its
shell takes over the tty (tty reopen / termios flush). The line sent by `sendln`
vanishes — the device neither echoes nor runs it — so the following `wait` blocks
forever and the rig sits dead.

This is a race, not a delay: `pause` before `sendln` only lowers the odds of hitting
the window, it can never close it. Evidence from a 45-cycle overnight power-cycle run
(For_AI/[COM121]_20260715): 3 cycles hung this way, and the swallowed sends landed at
the same DUT uptime (31.8-34.8s) as the 42 that worked. The `random: crng init done`
line those hangs share is a symptom, not the cause — it only appears because a hung
script stops power-cycling, letting the DUT reach uptime 89.7s it never otherwise sees.

Single-string `wait` aborts the script on timeout (deliberate, see CLAUDE.md), so the
TeraTerm idiom `wait` -> `if result = 0 then goto retry` cannot express a resend here.
Hence a new command rather than a semantics change:

    sendlnretry '<text>' '<confirm keyword>' [max attempts]

Sends, then waits for proof the device actually ran it, and resends if that proof does
not arrive. Attempts omitted = retry until it gets through. On success result=1; when
attempts run out result=0 and the script continues so it can handle the failure.

Semantics: clears the receive buffer before each send (a match can only come from this
send); on a hit consumes only up to the first occurrence, leaving the rest for the next
`wait`; deliberately no settle (the keyword appearing is itself proof). Per-attempt
timeout follows timeout/mtimeout when set, else 3s — unlike `wait`, 0 cannot mean
"forever" here since that would mean never retrying.

Not yet run against hardware: compiles clean (cross-built win-x64 on Linux), but the
DUT power-cycle rig is the first real execution.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MKF7C75bhA4ArQhyMpnsxU

CLAUDE.md

@@ -10,6 +10,8 @@ ETTerms 是一個 **C# .NET 8 WinForms** 的原生 Windows 終端機工作台，
 
 **進度：** Phase 1–5 ✅、Phase 6 ✅（TTL 引擎 + Group 同步，SSH 待驗收）、Phase 7 ✅（Settings/About）、Phase 8 ✅（PDU + Shell/ConPTY + SFTP + Settings 擴充）、Phase 9 ✅（Serial MCP server：**GUI 持有 COM port，MCP 經本機 named pipe 橋接**，AI 收發的資料即時以 `[AI]` 標色顯示在 GUI）、**Phase 10 ✅（v0.6.0）內建 AI Assistant**（見下）。打包待指示。
 
+**v0.7.1：** 新增 TTL 指令 **`sendlnretry '文字' '確認關鍵字' [最多送出次數]`**（`TTLInterpreter.SendLnRetry` + `WaitConfirm`）——送出後等確認關鍵字，沒等到就**重送**；次數省略 = 無限重送，命中 `result=1`、用完次數 `result=0` 且**繼續執行**（不中止腳本）。**動機**：裝置開機、console 剛被 shell 接手的瞬間會丟棄輸入（tty 重開 / termios flush），`sendln` 送出的整行無聲消失（裝置不回顯、不執行），後面的 `wait` 就永遠卡住；這是機率性的，`pause` 只能調機率、無法根治（實測 45 輪 power-cycle 中 3 輪中招，且**中招時間點與成功時完全重疊**）。**為何需要新指令而非用 `wait` 重試**：單字串 `wait` 逾時是 throw 中止腳本（刻意設計，見下方「注意事項」），TeraTerm 的 `wait`→`if result = 0 then goto retry` 重送寫法在 ETTerms 寫不出來。**語意**：每次送出前清空 `_recv`（確保比對到的是這次送出的回應）；命中只消費到**第一次**出現處，後續輸出留給接下來的 `wait`；刻意**不套 `SettleAndConsume` 的 settle**（關鍵字出現本身就證明裝置收到了）；每次等待逾時 `timeout`/`mtimeout` 有設就用設定值、**沒設預設 3 秒**（此處 0=無限等於永不重送，故不沿用 `wait` 的 0=無限）。⚠️ 確認關鍵字要挑「命令真的有跑」的輸出，**不要挑指令回顯**——tty echo 由核心產生，不保證命令被 shell 讀走。文件：[docs/ttl-script-reference.md](docs/ttl-script-reference.md#送出並確認sendlnretry)。
+
 **v0.7.0：** **AI Chat 改用 WebView2 渲染**（真氣泡 + Markdown + thinking 動畫泡）。訊息區從 RichTextBox 換成 `WebView2`：user 右泡 / AI 左泡、AI 回覆走 **Markdig** markdown→HTML（程式碼區塊/表格/清單）、送出後顯示會動的 thinking「…」泡（`AgentHost.Status "thinking"` → `showThinking()`，收到 `AssistantText` 時 `hideThinking()` 再加 AI 泡）。HTML 模板全內嵌於 `Ai/ChatHtml.cs`（`NavigateToString`,無外部依賴）,C# 經 `ExecuteScriptAsync` 呼叫 JS 函式;WebView2 async 初始化,就緒前的呼叫先入 `_pending` 佇列、`NavigationCompleted` 後 flush。使用者資料夾 `%LocalAppData%\ETTerms\WebView2`（避開 Program Files 唯讀）。底部控制列（輸入框/模型下拉/Send）仍 WinForms。新增 NuGet `Microsoft.Web.WebView2` + `Markdig`;依賴 WebView2 Runtime（Win11 內建,缺時 hint 顯示錯誤）。⚠️ **publish 要確認 WebView2 native（`runtimes/win-x64/native/WebView2Loader.dll`）有進產物**。**工具呼叫上限可設定**（`AppSettings.AiMaxToolRounds`,Settings → AI Assistant,`AgentHost` 建構子傳入）：**0 = 無上限**（自動化長跑;每輪燒 token,聊天視窗 Send 鈕在執行中變 **Stop**,經 `CancellationToken` 中止）,預設 30。
 
 **v0.6.0：** **內建 AI Assistant（Phase 10）** — 不經 Claude / Kiro，GUI 內建 ✨ AI 聊天**分頁**，自然語言驅動 serial + PDU。**AI 是 Workspace 的一種 pane**（工具列 `✨ AI Chat` 開啟，`WorkspaceView.Session` 抽象化為可容納 `SessionPage` 或 `AiChatView` 的 `Content`），可用 Layout 與 serial 分頁**並排同時用**（像 Claude/Kiro）；AI 分頁無 Group/Log/Script。**UI 走乾淨逐字稿風**（user 靠右 accent、AI 靠左、工具灰字、thinking 收進 Send 按鈕不洗版；與終端機美學一致，非氣泡——真氣泡+Markdown 的 WebView2 版列 v0.7.0）。**模型下拉**（右下角）打端點 `/v1/models` 列可選模型、即時切換並記住；**Settings 只留 Base URL / API Key / 系統提示詞,不再設 model**（`configured` 只看 Base URL）。**BYO endpoint**：`Settings → AI Assistant` 填 Base URL / Model / API Key（任意 OpenAI 相容 gateway：本機 Ollama、LiteLLM、公司 gateway、OpenAI…），**預設全空白＝功能停用**；🚫 **發佈版不含任何私人端點**，API key 存 Windows Credential Manager（`ETTerms/AiApiKey`）、Base URL/Model 存 settings.json，程式碼範例一律 `localhost`/假 IP。**架構（in-process，不經 MCP）**：`Ai/OpenAiChatClient`（極簡 OpenAI 相容 `/chat/completions`，HttpClient 非串流）+ `Ai/AgentHost`（手寫 agent loop，tool_calls→執行→role=tool 餵回→迴圈上限 8 輪）+ `Ai/AiTools`（serial list/attach/write/read 經 `SerialBridge`——與 MCP 同一路徑、AI 的 TX 照樣 `[AI]` 標色顯示在終端機；PDU connect/status/set_port/power_cycle 經 `ETTerms.PduCore`）。**安全**：破壞性 PDU 動作（關插座 / power-cycle）一律 `AiTools.ConfirmAsync` → GUI MessageBox（預設 No）確認，AI 不能自己斷電；每筆工具呼叫寫 AppLogger（`[AI tool] …`）。**刻意不引入 `Microsoft.Extensions.AI`**（手寫 client+loop，依賴最小、對任意 gateway 相容性自己掌控）。既有 SerialMcp/PduMcp（Settings → AI MCP）**不受影響**，繼續服務外部 AI CLI；兩者是「內建 agent（in-process）vs 外部 AI（MCP 跨行程）」的分工。新增 `src/ETTerms/Ai/`（3 檔）+ `App/AiChatView.cs`，`ActivityRail` 加 `Ai` view，`SettingsView` 加 AI Assistant 分頁，`AppSettings` 加 `AiBaseUrl/AiModel/AiSystemPrompt`。