Holding this open — data layer + protocol plumbing is sound and correctly addresses #2132, but the user-visible feature is incomplete in a couple of material ways. Listing the gaps for the follow-up pass:

Required before merge

1. Wire NavtexApplet into AppletPanel. The applet class is built and setRadioModel() is callable, but there's no registration in AppletPanel.cpp and no construction site in MainWindow.cpp. Without that, the NAVTEX UI is unreachable from the running app.
2. Add a NAVTEX activate / deactivate command path. Per the FlexLib analysis (NAVTEX.cs, v4.2.18), the radio activates NAVTEX by being put into mode NT on a slice at 518 / 490 / 4209.5 kHz. The applet currently only exposes "Send" and gates it on status being Active/Transmitting — but the user has no way to make the status Active. Either:
   • Expose Activate/Deactivate buttons that send the slice-mode change, or
   • Auto-activate when the applet is opened and the active slice mode allows it
   • Look at Radio.cs ParseStatus around line 3480 and NAVTEX.cs for the exact activation sequence FlexRadio's reference uses.

Worth doing in the same pass

3. Quote-escape msg_text="..." in NavtexModel::sendMessage. The current arg(msgText) substitution will break the radio's command parser if the message contains a ". Standard escape (\" → \\\") before wrapping in quotes.
4. Unit test for the message state machine. NavtexModel is unit-testable (no GUI deps beyond QObject) — a tests/navtex_model_test.cpp covering Pending → Queued → Sent, send-failure path, and orphan navtex sent for unknown idx would be cheap insurance and matches the existing test pattern (e.g. iambic_keyer_test, cwx_panel_test).

Already correct — no changes needed

• Status enum parsing is case-insensitive (matches FlexLib's Enum.TryParse).
• Pending-by-sequence tracking is sound — three-state promotion via the reply handler then status broadcast.
• NT mode tolerance is threaded correctly through MainWindow, RxApplet, VfoWidget, and SliceModel.
• USB-family classification of NT mode in SliceModel::applyStatus matches the protocol semantics.
• parseSentStatus correctly handles the Multi-Flex case where another client's send produces a navtex sent we observe (synthesizes a record).
• commandReady / replyCommandReady wiring through RadioModel follows the existing model-pattern.
• Applet header explicitly notes "visual design/placement is maintainer-only per CLAUDE.md" — agent self-restrained correctly.

cc @jensenpat — if any of this lands as a maintainer-driven follow-up rather than another AetherClaude pass, the activation-command piece is the main protocol-design call (auto-activate vs explicit button).

Closing in favor of PR #2186, which carves out just the data-layer + protocol-plumbing work (the actual scope of #2132). The full review feedback on this PR included two required-before-merge items:

1. Wire NavtexApplet into AppletPanel (unaddressed for 3 days)
2. Add a NAVTEX activate/deactivate command path (also unaddressed)

Both of those are UX decisions that #2132 explicitly carved out as maintainer-only. Rather than leave the PR open indefinitely waiting for the bot to address feedback that requires UX design, I've replayed just the protocol/data-layer work as PR #2186 with two improvements caught during the carve-out:

• Quote-escape msg_text="..." (would have broken on embedded " or \\)
• Fix unreachable failure-path in handleSendResponse (failure responses arrive with empty body, which made the old if (indexStr.isEmpty()) return; short-circuit before the error handler could run)

Plus a 21-assertion unit test for the state machine.

The NavtexApplet UI work remains as a future maintainer-driven follow-up — when the activation UX is decided, the data layer is ready to plug into.

Bot couldn't be modified (maintainerCanModify: false), so this is the cleanest path.