fix(desktop): extend startup window-reveal timing fix to Linux

[srirsiva]

Problem

On Linux, the desktop app's main window sometimes opens as a collapsed
10x10 window or renders fully invisible/transparent, both on fresh launch
and intermittently after in-app navigation.

Root cause

desktop/src-tauri/src/lib.rs creates the main window hidden
("visible": false) and pre-maximized ("maximized": true,
"transparent": true in tauri.conf.json).
tauri_plugin_window_state restores the saved geometry asynchronously.
The initial-window-reveal plugin is supposed to wait for that restore to
settle (via wait_for_stable_initial_window_geometry + an opaque
set_initial_window_backing/clear_initial_window_backing sequence)
before calling window.show() — but this entire wait/backing mechanism is
#[cfg(target_os = "macos")]-gated only. On Linux, on_webview_ready just
calls reveal_initial_window() immediately, racing the window-state
restore and landing the window at a transient/degenerate size.

Fix

Widens the existing timing logic (unchanged — no behavioral changes to the
polling algorithm itself) from #[cfg(target_os = "macos")] to
#[cfg(any(target_os = "macos", target_os = "linux"))]:

• the INITIAL_RENDER_READY_EVENT const and use tauri::Listener; import
• set_initial_window_backing / clear_initial_window_backing
• wait_for_stable_initial_window_geometry
• the shared wait-then-reveal-then-clear-backing sequence in
  on_webview_ready

Windows is deliberately excluded, left on today's immediate-reveal
path — there's no reported bug there, and Win32's SetWindowPos/
ShowWindow are believed to apply synchronously (unlike GTK's
request/allocate-on-next-idle-iteration model), which is plausibly why
this race hasn't surfaced on that platform. Happy to revisit if a Windows
report ever comes in.

Verified window.set_background_color(...) is a real, working call on
Linux/GTK (traced through tauri-runtime-wry → tao's
platform_impl/linux/window.rs, sets a real GTK CSS background on the
outer ApplicationWindow), not a macOS-only stub — same technique applies
unchanged.

Testing

• just desktop-tauri-check, desktop-tauri-fmt-check,
  desktop-tauri-clippy (zero warnings), desktop-tauri-test — all pass.
• Manual repro on Zorin OS (GNOME/X11, GTK): repeated launches of an
  unpatched build intermittently collapsed the window; after this change,
  0 occurrences across repeated launches, using a properly-built
  (pnpm tauri build) release binary.
• Did not test macOS or Windows locally (no rig available) — the macOS
  path is unchanged by this diff, and Windows is explicitly out of scope
  per the reasoning above.
• Did not run the Flutter/mobile test suite locally (not set up on this
  machine) — this change is scoped to desktop/src-tauri/ only, no
  mobile/web impact.

This overlaps with #2500 in problem space (both touch desktop rendering
reliability) but not in code — #2500 doesn't touch
desktop/src-tauri/src/lib.rs.