fix(macOS): keep window controls reachable in fullscreen

[Waynting]

Description

On macOS, entering fullscreen currently removes every window control the app has.

The window is built with decorations: false, so the red/yellow/green buttons are drawn by src/window/TitleBar.tsx rather than by macOS. App.tsx renders that bar as !isWindowFullScreen && <TitleBar />, so going fullscreen unmounts it — and the green button is the only fullscreen toggle in the app. Entering fullscreen therefore removes the way back out of it, along with close and minimize. macOS does not fill the gap either: with no titled window there are no native controls for it to reveal.

This PR keeps the bar mounted in fullscreen and adds a real shortcut for window fullscreen.

Fixes #1585.

Type of Change

• Bug fix
• New feature
• Breaking change
• Performance improvement
• Code refactoring
• Documentation update
• UI/UX improvement
• Build/CI or Dependency update

Changes Made

• src/App.tsx — keep TitleBar mounted when the window is fullscreen.

  Revealing it on hover was the first thing I tried, and it does not work: sliding it in when the pointer reaches the top edge is the same gesture that summons the macOS menu bar in fullscreen, so the two land on the same strip and the menu bar intermittently covers the buttons. A bar that stays put is reachable without ever touching the top edge, which sidesteps the conflict entirely.

  The in-app image fullscreen (isFullScreen, F) still hides the bar as before, so the distraction-free view is unaffected — that mode has Esc to get out of it, which window fullscreen did not.

• src/App.tsx — topUiEstimation assumed the bar was absent in fullscreen and under-measured the top chrome by 50px, which skewed the computed bottom panel height. It tracks the bar again.

• src/utils/keyboardUtils.ts, src/hooks/useKeyboardShortcuts.ts — add a toggle_window_fullscreen keybind, default F11, rebindable in Settings.

  The existing toggle_fullscreen action toggles the in-app image preview (isFullScreen), not the window (isWindowFullScreen), and only fires while an image is selected — so no platform had a shortcut for window fullscreen at all.

• src/hooks/useKeyboardShortcuts.ts — handle Cmd+Ctrl+F as a builtin on macOS.

  The default Tauri menu already binds this chord to View > Enter Full Screen, but that item does not fire for a decorationless window. I verified this rather than assuming it: logging every keydown shows Cmd+Ctrl+F arriving in the webview with {meta: true, ctrl: true}, so macOS is not consuming it as a menu key equivalent, which matches the report in BUG: Unable to do fullscreen #1585. It cannot be expressed as a rebindable combo either, because normalizeCombo folds Cmd and Ctrl into a single ctrl token.

• 13 locale files — added the string for the new keybind rather than leaving the other 12 to fall back to English.

Screenshots/Videos

Fullscreen with the bar kept in place. The macOS menu bar still slides down when the pointer touches the very top — that is native behaviour for any fullscreen app and is not suppressed — but it no longer covers the window controls:

Testing

• These changes were tested locally by a human and confirmed to work.
• I haven't added any automated tests to the code because the codebase currently lacks a test suite.

Verified on the hardware below, in a tauri dev build:

• Green button enters fullscreen; the controls stay visible and stay put; red closes and green leaves fullscreen.
• Bringing down the macOS menu bar no longer hides the controls.
• Cmd+Ctrl+F toggles window fullscreen (it did nothing before this change).
• F11 is intercepted by macOS for Mission Control and does not reach the app, which is expected. It is the default because Windows and Linux had no window-fullscreen shortcut at all, and it is rebindable for anyone who wants something else.

tsc --noEmit reports no errors in the changed files, eslint output is unchanged from main (the pre-existing no-explicit-any count is identical), prettier --check passes, and vite build succeeds.

Test Configuration:

• OS: macOS 15
• Hardware: Apple Silicon (aarch64-apple-darwin)

Checklist

• My code follows the project's code style
• I haven't added unnecessary AI-generated code comments
• My changes generate no new warnings or errors

Additional Notes

While tracing this I also hit a related but separate problem — after a library is loaded, the only in-session entry point for switching folders is the hover-gated + Add folder row, and it disappears entirely in the compact and wide layouts. That is a UI decision rather than a bug, so I filed it separately as #1702 instead of bundling it here.