ui: the header bar's frame is a .ui file, closing item 10's last row

src/ui/header-bar.ui holds the bar: the time-window control's slot, the trigger, pause and
events group with the separator that marks where the view's controls end, and the five at
the far end. What stays in code is everything that acts on the model -- the overflow
menu's rows, the window control itself, and every handler.

The order is the file's, which is the part the code used to explain in three comments: a
<child type="end"> is added leftwards-from-the-right in document order, so the screen reads
the reverse of it -- cursors, measurements, math, sidebar, menu.

The first start child is a *slot* and not the control, and that is the one thing this move
could not do naively: gtk_header_bar_pack_start() appends after whatever a file has already
packed, so the control -- which is code, its menu's rows coming from the buffer's limits --
would have landed to the right of the whole group instead of at its head.

The probe is the check, and every header reading is byte-identical to before the move: 12
lines of `header:` (window_button_w=130 bar_w=756), `window control:`, `panels:`, both
width-probe frames and all seven layout-probe lines. Only `badge frames:` differs, and it
is a frame counter. check_ui: 14 ok, 0 failed.

src/ui/header-bar.ui

@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- SPDX-License-Identifier: MIT -->
+<!-- SPDX-FileCopyrightText: 2026 Martino Ferrari -->
+<!--
+  The header bar: the time-window control's slot, the trigger, pause and events group with the separator that
+  marks where the *view's* controls end, and the five at the far end.
+
+  The bar carries only the controls you reach for *while watching a signal*; everything you set up once lives
+  in the overflow menu, which is code — its rows act on the `RowSet` directly and two of them are toggles
+  whose state the rest of the interface reads, so a `GMenu` model would only add a second copy of that state.
+
+  The order is the file's, and it is the one thing here that is not self-evident: `pack_end()` lays its
+  children out right to left, so a `<child type="end">` is added leftwards-from-the-right in document order
+  and the screen reads the reverse of it — cursors, measurements, math, sidebar, menu.
+
+  The first start child is a slot and not the control: the time-window control is code (its menu's rows come
+  from the buffer's limits), and `gtk_header_bar_pack_start()` appends *after* whatever a file has already
+  packed, so a control added by code would land to the right of this whole group instead of at its head.
+
+  The events toggle starts hidden: the event history is a *trigger* thing, and asking for it is one click
+  from the mode that produces it.
+-->
+<interface>
+  <object class="GtkHeaderBar" id="header_bar">
+    <child type="start">
+      <object class="GtkBox" id="window_control_slot">
+        <property name="orientation">horizontal</property>
+      </object>
+    </child>
+    <child type="start">
+      <object class="GtkToggleButton" id="trigger_toggle">
+        <property name="icon-name">udpscope-trigger-symbolic</property>
+        <property name="tooltip-text" translatable="yes">trigger mode: freeze the view and show one captured event at a time</property>
+      </object>
+    </child>
+    <child type="start">
+      <object class="GtkToggleButton" id="pause_button">
+        <property name="icon-name">media-playback-pause-symbolic</property>
+        <property name="tooltip-text" translatable="yes">pause acquisition</property>
+      </object>
+    </child>
+    <child type="start">
+      <object class="GtkSeparator">
+        <property name="orientation">vertical</property>
+      </object>
+    </child>
+    <child type="start">
+      <object class="GtkToggleButton" id="events_toggle">
+        <property name="icon-name">udpscope-events-symbolic</property>
+        <property name="tooltip-text" translatable="yes">the event history: the triggered acquisitions kept in the cache, with a picture of each</property>
+        <property name="visible">0</property>
+      </object>
+    </child>
+    <child type="end">
+      <object class="GtkMenuButton" id="menu_button">
+        <property name="icon-name">open-menu-symbolic</property>
+        <property name="tooltip-text" translatable="yes">view options</property>
+      </object>
+    </child>
+    <child type="end">
+      <object class="GtkToggleButton" id="sidebar_toggle">
+        <property name="icon-name">sidebar-show-symbolic</property>
+        <property name="tooltip-text" translatable="yes">show the side panel</property>
+        <property name="active">1</property>
+      </object>
+    </child>
+    <child type="end">
+      <object class="GtkToggleButton" id="math_toggle">
+        <property name="icon-name">udpscope-math-symbolic</property>
+        <property name="tooltip-text" translatable="yes">channels derived from the others by a graph of operations: gain, absolute value, filters, sums and the rest. An enabled one is acquired, plotted and measured exactly like a signal</property>
+      </object>
+    </child>
+    <child type="end">
+      <object class="GtkToggleButton" id="measures_toggle">
+        <property name="icon-name">udpscope-measure-symbolic</property>
+        <property name="tooltip-text" translatable="yes">compute a value over the visible window of a signal, and optionally mark it on the plot</property>
+      </object>
+    </child>
+    <child type="end">
+      <object class="GtkToggleButton" id="cursors_toggle">
+        <property name="icon-name">udpscope-cursors-symbolic</property>
+        <property name="tooltip-text" translatable="yes">the cursor instruments: two times, two levels, or the two read off each trace where they cross</property>
+        <property name="active">0</property>
+      </object>
+    </child>
+  </object>
+</interface>