Linux: support XDG activation tokens / startup IDs when presenting an existing BrowserWindow

Version: Electrobun 2.0.2, Hutch 0.27.1, Linux GTK window path.

A second launch of an application may need to present an already-existing window using the new launch's Wayland activation token or X11 startup ID. In the 2.0.2 JavaScript SDK, BrowserWindow.activate() and show() accept no token. Restoring a minimized window now requests activation, but this does not expose the launch token to an embedding that needs to forward it to an existing window.

Our embedding currently obtains the window pointer and uses a small GTK3 helper to apply gdk_wayland_display_set_startup_notification_id() or gtk_window_set_startup_id() on the GTK thread before presenting it. We would prefer a supported Electrobun API instead of maintaining toolkit/thread-lifetime FFI.

Requested API: an optional activation token/startup ID argument to a public present/activate operation, applied on the native UI thread before showing/activating an existing or restored window. Keep tokenless behavior unchanged and report unavailable token application without claiming focus was granted by the compositor.

Suggested regression coverage: existing window, minimized window, tokenless launch, malformed/absent token, Wayland and X11 native paths. Validate actual compositor behavior separately from a mocked SDK call.

Evidence:

• https://github.com/blackboardsh/electrobun/blob/v2.0.2/package/src/sdks/main/core/BrowserWindow.ts
• https://github.com/blackboardsh/electrobun/blob/v2.0.2/docs/src/content/docs/electrobun/guides/changelog/v2-0-2.mdx

This report is based on the versioned SDK and our integration helper. It is not a newly executed compositor reproduction, and it does not claim that a particular compositor is defective.

Proposed fix boundary

Expose token-bearing activation through the normal SDK/native boundary. No app-specific policy, new window wrapper, or dependency on our local helper.