fix: instant hide the window and proces in background

[Flash303]

This pull request introduces improvements to window management permissions and the quit handler behavior in the application. The main focus is on allowing the window to be hidden and ensuring the window is hidden before executing quit logic.

Window management enhancements:

• Added the core:window:allow-hide capability to the default.json configuration, enabling the application to programmatically hide the window.

Quit handler improvements:

• Updated the ensureQuitHandler function in runtime.ts to call win.hide() when a close is requested, ensuring the window is hidden before running quit callbacks.

[Flash303]

Related to #94

[kipavy]

Thanks @Flash303 — your diagnosis was right, and I could confirm it in the code: ensureQuitHandler() in src/plugins/runtime.ts preventDefaults the close and then awaits every plugin onBeforeQuit callback with the window still on screen. gist-sync pushes to GitHub in that hook, hence the ~2s. With no plugin registering a quit hook the handler is never installed at all, which is why I never hit this myself.

I've opened #97, which takes your approach (hide first, let the sync finish in the background) plus two safety fixes:

• Only hide when a quit hook is actually registered — otherwise close stays immediate as before.
• Arm the Rust-side exit up front with a fallback timer and call it from a finally, so a throwing hook or a failed invoke can't leave a hidden window over a live process.

It also adds unit tests for the handler, and I gated it on a real build under Xvfb/WebKitGTK with a test plugin whose quit hook runs ~2.4s: the window reports invisible from 303ms onward while the hook is still running, and the process exits 2.97s after the close — right after the hook, not on the fallback. With no hook registered, exit was ~240ms.

I don't have a Windows machine to check against, so if you get a chance to build #97 (or try the next dev build) with gist-sync enabled and confirm the close feels instant on your side, that would be great. I'll most likely close this PR in favour of #97, but the fix is yours — credited there.

[kipavy]

Superseded by #97, which carries this fix with the extra safeguards. Thanks again @Flash303.

[Flash303]

Superseded by #97, which carries this fix with the extra safeguards. Thanks again @Flash303.

Np