fix(host): restore terminal links and window controls

[gmanvelian]

What changed

• Restore reliable terminal link activation with Ctrl+primary-click and a context-menu Open Link action.
• Let registered system handlers receive link schemes, including application and local-file links, to match Ghostty's behavior.
• Always render the Limux libadwaita header and guarantee minimize, maximize, and application-close controls.
• Add a linked implementation handoff at docs/session-logs/2026-08-10-terminal-links-and-window-controls.md.

Why

Terminal links could become inert when a user Ghostty configuration did not define an open_url binding. Separately, on Wayland compositors that advertise zxdg_decoration_manager_v1 (notably KWin/Plasma), Limux suppressed its header even though libadwaita had already selected client-side decorations, leaving no window controls.

Validation

• cargo fmt --check
• LD_LIBRARY_PATH=ghostty/zig-out/lib cargo test -p limux-host-linux (227 passed)
• cargo clippy -p limux-host-linux -- -D warnings
• cargo build --release -p limux-host-linux --bin limux

[bvolpato]

Would it make sense to keep the existing http/https/mailto allow-list here, or add an explicit confirmation for other schemes? Terminal output can control OSC 8 links, so this now sends file://, GVFS, and custom application schemes straight to GIO/xdg-open. Is that a concern?

[bvolpato]

Could we rebase this on current main and preserve KWin server-side decoration path? main now requests server-side decorations after present(), while this block always forces client-side decorations and currently conflicts with that code. Is losing that KWin behavior a concern?