fix(linux): improve Wayland startup stability

[boeserwolf]

Before Submitting This PR

Please confirm you have done the following:

• I have searched existing issues and pull requests (including closed ones) to ensure this isn't a duplicate
• I have read CONTRIBUTING.md

If this is a feature or change that was previously closed/rejected:

• I have explained in the description below why this should be reconsidered
• I have gathered community feedback (link to discussion below)

Human Written Description

On CachyOS (Arch) with KDE Wayland, Handy could hit a Wayland protocol error on startup when the recording overlay path initializes gtk-layer-shell.
The app startup then became unstable even though the regular overlay window path itself is fine.
This change keeps the overlay available on KDE Wayland, but skips only the gtk-layer-shell initialization there and falls back to the regular always-on-top overlay behavior.

Related Issues/Discussions

Fixes #
Discussion:

Community Feedback

Maintainer feedback in this PR requested a clearer Linux-specific explanation.
I reworked the patch to a smaller, KDE-Wayland-scoped fix and validated it locally on CachyOS KDE Wayland.

Testing

• Environment: CachyOS (Arch), KDE Plasma, Wayland
• Reproduced before fix: startup instability/protocol error in overlay init path
• Verified after fix:
  • app starts reliably
  • recording overlay still works on KDE Wayland (fallback path)
  • no macOS/Windows behavior changes
• Validation command: cargo check --manifest-path src-tauri/Cargo.toml
• Also validated via local AppImage run

Screenshots/Videos (if applicable)

N/A

AI Assistance

• No AI was used in this PR
• AI was used (please describe below)

If AI was used:

• Tools used: Codex (gpt-5.3-codex)
• How extensively: Assisted with debugging, patching, and validation.

[cjpais]

Can you explain the issue and then the fix in more detail please, I don't have good visibility into Linux

[boeserwolf]

Quick update: I reworked this PR to a narrower fix after more testing on CachyOS KDE Wayland.

The earlier approach in this thread is superseded.
Current fix is only:

• skip gtk-layer-shell init on KDE Wayland
• keep the overlay active via the regular window fallback path

So this no longer disables overlay on KDE Wayland, and it no longer includes unrelated startup env changes.

[vpsone]

This PR, causing an overlay to act as a window again in KDE, prevents it from pasting in the active window.

[vpsone]

On version 0.7.3, it was working well.

[cjpais]

@vpsone okay im not sure what to do because people also experiencing issues with that code so we need a better solution overall...

[vpsone]

Recently, the layer-shell protocol has been added for Linux, but this PR skips it for KDE. For me, it is working fine on v0.7.3; all I have to do is install gtk-layer-shell. I think reverting it, will fix the issue for KDE.

[cjpais]

I understand @vpsone but see the issue

On CachyOS (Arch) with KDE Wayland, Handy could hit a Wayland protocol error on startup when the recording overlay path initializes gtk-layer-shell.

What do you think on this? Again right now I don't have visibility into Linux deeply, and just trying my best to support everyone

[vpsone]

@cjpais This issue may be caused by a missing gtk-layer-shell dependency, but we'll need @boeserwolf to confirm it.

[boeserwolf]

This PR, causing an overlay to act as a window again in KDE, prevents it from pasting in the active window.

Thanks for pointing this out.

You are right. This PR can cause a regression on KDE where the overlay behaves like a regular window again, and that can interfere with pasting into the currently active app.

Sorry for the regression and the noise here. That was not my intention. I will try to dig deeper into the root cause and, if needed, follow up with a smaller and safer fix.