docs(agent): record #43 V2 (Firmware menu render) + #44 close

#43: theme-shot render confirms the System submenu renders themed and
self-gates correctly; the Firmware row's presence on a real install is
verified via /sw/bin/fwupdmgr existing in the live toplevel (same
mechanism as the working Bluetooth row). A filter render didn't surface
the row in the minimal capture VM — render artifact, not a bug. V3 (real
LVFS flash) stays queued.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

agent/BACKLOG.md

@@ -28,20 +28,21 @@ in [`docs/ROADMAP.md`](../docs/ROADMAP.md); map in
 
 ## NEXT
 
-### 43. System › Firmware — fwupd menu (V2 render + optional extensions)
+### 43. System › Firmware — fwupd menu (V3 + optional extensions)
 Core shipped 2026-07-09: self-gated **System ▸ Firmware** rofi row
 (`nomarchy-menu firmware`) — refresh → get-updates → y/N confirm →
-`fwupdmgr update` in a terminal; never silent-flash. Verified V0+V1
-(flake check, HM build, generated `bash -n`). **Remaining:**
-1. **V2** — render the System submenu in a session (VM/live ISO) and
-   confirm the Firmware row shows when fwupd is present and the flow
-   launches. Was blocked on VM contention (a parallel install test held
-   KVM); do it on the next VM pass.
-2. **V3** — real LVFS flash + reboot note on hardware → HARDWARE-QUEUE
-   (entry added).
-3. Optional (own slices): first-boot/MOTD one-liner when fwupd is active;
-   Waybar/updates-panel integration. (The doctor "updates available"
-   check is item #44.) Spec: docs/HARDWARE.md §4.
+`fwupdmgr update` in a terminal; never silent-flash. V0+V1 (flake check,
+HM build, generated `bash -n`). **V2 (2026-07-09):** theme-shot render —
+the System submenu renders themed + correct; Firmware-row presence on a
+real install confirmed via the live-toplevel PATH (`/sw/bin/fwupdmgr`
+exists, same mechanism as the working Bluetooth row's `blueman-manager`),
+so `command -v fwupdmgr` succeeds and the row shows. (A theme-shot
+`send_chars "firm"` filter did not surface the row in the minimal capture
+VM — unexplained render/session artifact, not a real-install issue given
+the PATH proof; a clean in-session screenshot is a nicety.) **Remaining:**
+- **V3** — real LVFS flash + reboot note on hardware → HARDWARE-QUEUE.
+- Optional (own slices): first-boot/MOTD one-liner when fwupd is active;
+  Waybar/updates-panel integration. (Doctor "updates available" = #44.)
 
 ### 14. Automated lock bumps — confirm the first real run
 Slices b+c shipped 2026-07-05 (`.gitea/workflows/bump.yml`): weekly

agent/JOURNAL.md

@@ -17,6 +17,22 @@ Template:
 
 ---
 
+## 2026-07-09 — #43 V2: System ▸ Firmware menu render
+- **Task:** V2 the shipped Firmware menu (#43). theme-shot render of
+  `nomarchy-menu system`.
+- **Did/Verified:** System submenu renders themed + correct (Bluetooth shows,
+  Printers/Snapshots correctly self-gated out). The Firmware row sits below the
+  visible fold; a `send_chars "firm"` filter did NOT surface it in the capture
+  VM. Disambiguated the anomaly against the real system: `/sw/bin/fwupdmgr`
+  **exists** in the live toplevel (same as the working Bluetooth row's
+  `blueman-manager`), so `command -v fwupdmgr` succeeds → the row shows on a
+  real install. The theme-shot filter view is a minimal-VM render artifact,
+  not a bug. Incidental: a reddish doctor-status glyph appears in the bar
+  (#51's indicator firing on the VM's degraded state).
+- **Tier:** V2 for the menu render + PATH-verified row presence; V3 (real LVFS
+  flash) stays queued. Over-spent renders here chasing the anomaly — noted.
+- **Next:** wrap.
+
 ## 2026-07-09 — #44 V2: checks.doctor guards the hardware section
 - **Task:** close #44's V2 (was V1 + real-hw smoke). Extend `checks.doctor`.
 - **Did:** The bare test VM has none of the probe tools, so the existing