help: a tinier (i), hints beside their controls, and the tour starting in the chooser

The contextual help becomes the affordance the ask names: a plain (i)
(`dialog-information-symbolic`) at **16x16**, and one that sits beside the
control it explains rather than only in a pane's heading.

- The mark: `GtkMenuButton` ignores `min-width` on the widget and a size
  request, so the size is made in `install_css()` on all three nodes (outer
  `menubutton`, its `button` subnode, the glyph). Measured 16x16 against the
  default 34x34; the dump prints it as `hint=WxH`, measured with
  `gtk_widget_compute_bounds()` on the first *visible* hint.
- More sites: `events_record` (the "record events" switch in the trigger
  panel), `trigger_advanced` (the pre-trigger share row), `signals_config`
  (the signals pane's hint line, wrapped in a box so a hint can join it).
  Hints join as siblings, so none can cover a switch, pencil or dropdown.
- The source chooser gets its own layer -- `chooser_sources` (a new heading
  above the saved-source list) and `chooser_waveform` (the waveforms action
  row) -- built with the one `context_help_button()` both windows use and
  re-synced by its Help menu's toggle. The form's `AdwEntryRow`s cannot host a
  sibling hint, so none is invented for the host/port fields.
- The tour is one implementation over two windows: `ui_impl::TourView` plus a
  list of `TourStop`s; each window keeps its own table. A walk that passes its
  last stop calls `on_done`, and the chooser's sets `Config::tour_pending`, so
  a first run is one tour that crosses from the chooser into the app. The
  chooser's tour auto-starts from `settings.tour_seen` exactly as the window's
  does, and its "Guided tour" row now starts *it* instead of only requesting
  the window's.
- Probes: `UDPSCOPE_PROBE_CHOOSER_TOUR=1` / `UDPSCOPE_PROBE_CHOOSER_TOUR_MS`,
  the hint size in the `help layer:`/`[helpui] contextual on:` lines, and the
  chooser's hints in its `chooser ui:` line. Docs updated in
  invariants-gtk-and-chrome.md, probe-readings.md and verification.md.

src/ui_widgets.cpp

@@ -68,7 +68,20 @@ void install_css() {
       ".udpscope-tour-dim { background-color: rgba(0, 0, 0, 0.45); }\n"
       ".udpscope-tour-spot { border: 2px solid @accent_bg_color; border-radius: 8px; }\n"
       ".udpscope-tour-card { background-color: @window_bg_color; border: 1px solid @borders;"
-      " border-radius: 12px; padding: 12px; box-shadow: 0 3px 12px rgba(0, 0, 0, 0.45); }\n";
+      " border-radius: 12px; padding: 12px; box-shadow: 0 3px 12px rgba(0, 0, 0, 0.45); }\n"
+      // The contextual-help "(i)": a *mark*, not a button. Adwaita's menu button is a 34x34 control
+      // (a 24 px floor plus 5 px of padding) with a 16 px glyph, which beside a heading reads as a
+      // second toolbar button -- the size the ask calls too big. Measured on libadwaita 1.10: the
+      // outer `menubutton` node *and* its `button` subnode both carry a floor and padding, and a class
+      // selector on either alone leaves the other at 34 (`min-width` on the widget itself is ignored
+      // by `GtkMenuButton`'s measure, and so is a size request -- tried both). Zeroing all three --
+      // the outer node, the subnode and its glyph -- is what brings it to **16x16**: the icon's own
+      // size and nothing else, because a `min-width` is a floor, not a cap, so 16 px is where a 16 px
+      // Adwaita glyph stops. That is the reading `hint=WxH` in the dump prints.
+      "menubutton.udpscope-hint { min-width: 0; min-height: 0; padding: 0; margin: 0; }\n"
+      "menubutton.udpscope-hint > button { min-width: 0; min-height: 0; padding: 0; }\n"
+      "menubutton.udpscope-hint > button > image { min-width: 12px; min-height: 12px;"
+      " -gtk-icon-size: 12px; }\n";
   GtkCssProvider* p = gtk_css_provider_new();
   gtk_css_provider_load_from_string(p, kCss);
   gtk_style_context_add_provider_for_display(gdk_display_get_default(),