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/udpscope-ui.gresource.xml

@@ -20,6 +20,7 @@
     <file preprocess="xml-stripblanks">math-panel.ui</file>
     <file preprocess="xml-stripblanks">math-editor.ui</file>
     <file preprocess="xml-stripblanks">events-pane.ui</file>
+    <file preprocess="xml-stripblanks">header-bar.ui</file>
     <file preprocess="xml-stripblanks">trigger-panel.ui</file>
     <file preprocess="xml-stripblanks">signals-panel.ui</file>
   </gresource>