breadhelp: add --screenshot CLI mode for automated capture

Three views ("home", "learn", "ask") — one per tab in the Home/Learn/Ask
Stack, switched via the same set_visible_child_name the tab switcher
itself uses, then captured as a full known-size canvas (the window is a
plain top-level, not layer-shell).

Plumbed through breadhelp's own cli::Action/parse() (three more fields,
same shape as force_onboard/autostart/suggest) rather than clap, matching
the app's existing non-clap idiom.

The HANDLES_COMMAND_LINE + thread_local HANDLE singleton architecture
needed one addition beyond the usual NON_UNIQUE-flag fix: every
invocation (including a --screenshot one) normally forwards to the
already-built window over D-Bus and reuses it — worse than the plain
GApplication case in the other apps, since here it's not just "message
the existing instance" but literally switching tabs on and re-capturing
the operator's real, live help-center window. NON_UNIQUE is now set
whenever --screenshot is present in argv (checked before the
Application is even built, since cli::parse() only runs per-invocation
inside connect_command_line).

src/ui/window.rs

@@ -16,6 +16,7 @@ const DEFAULT_TAB: &str = "home";
 struct Handle {
     window: ApplicationWindow,
     home: Home,
+    stack: Stack,
 }
 
 thread_local! {
@@ -39,6 +40,11 @@ pub fn present(app: &Application, action: Action) {
         let handle = cell_ref.as_ref().unwrap();
         let display = WidgetExt::display(&handle.window);
 
+        if let Some(req) = action.screenshot_request() {
+            crate::screenshot::dispatch(&handle.window, &handle.stack, req);
+            return;
+        }
+
         if action.force_onboard {
             tour::restart(&display);
             return;
@@ -131,5 +137,5 @@ fn build(app: &Application) -> Handle {
     // independently of this window (see `tour::start`) — it never needs to
     // be shown at all until the user explicitly opens it later.
 
-    Handle { window, home }
+    Handle { window, home, stack }
 }