feat: intercept GDK button 8/9 for mouse back/forward navigation

WebKitGTK does not propagate XButton1/XButton2 (buttons 8 and 9) into
DOM events — event.button and event.buttons are always 0 for these
clicks. This prevents the frontend from detecting hardware back/forward
mouse buttons for history navigation.

Solution: patch Wails' window.c on Linux to intercept button-press-event
at the GTK signal level (before WebKit processes it). For button 8/9 we
call webkit_web_view_run_javascript() to dispatch a native CustomEvent
('verstak:navigate-back' / 'verstak:navigate-forward') into the page,
allowing the frontend to navigate history without any workaround on the
JS side.

The patch is applied automatically during build via scripts/build.sh:
  go mod vendor → patch -p0 < patches/window.c.button-press.patch
Vendor directory is gitignored.

patches/window.c.button-press.patch

@@ -0,0 +1,27 @@
+--- vendor/github.com/wailsapp/wails/v2/internal/frontend/desktop/linux/window.c
++++ vendor/github.com/wailsapp/wails/v2/internal/frontend/desktop/linux/window.c
+@@ -329,6 +329,24 @@
+     if (event->button == 3)
+     {
+         return FALSE;
++    }
++
++    // Handle mouse back/forward buttons (GDK button 8 = Back, button 9 = Forward)
++    // WebKitGTK doesn't propagate these correctly to DOM, so we dispatch custom events
++    // that the frontend can listen to for history navigation.
++    if (event->button == 8)
++    {
++        webkit_web_view_run_javascript(WEBKIT_WEB_VIEW(widget),
++            "window.dispatchEvent(new CustomEvent('verstak:navigate-back'));",
++            NULL, NULL, NULL);
++        return TRUE;
++    }
++    if (event->button == 9)
++    {
++        webkit_web_view_run_javascript(WEBKIT_WEB_VIEW(widget),
++            "window.dispatchEvent(new CustomEvent('verstak:navigate-forward'));",
++            NULL, NULL, NULL);
++        return TRUE;
+     }
+ 
+     if (event->type == GDK_BUTTON_PRESS && event->button == 1)