fix(qt): offer notifications only where a toast can actually arrive

`system_notifications_supported` answered `cfg!(windows)` in an earlier draft
and then a flat `false`; both were wrong in opposite directions. It now asks
the machine.

Setting the process AppUserModelID is necessary and NOT sufficient. An
unpackaged desktop app receives toasts only once Windows can RESOLVE that id,
through either a Start-menu shortcut carrying System.AppUserModel.ID or the
matching AppUserModelId registry key. The MSI writes both. A portable unzip has
neither, and every toast it raises is dropped in silence -- no error, no log,
nothing to point at.

So the row is offered on the strength of the registry key, read once at
document-build time. An MSI install sees it and gets the setting; a portable or
dev build does not, and the row stays hidden rather than presenting a switch
that can never produce a notification. That is the same "renders, persists and
drives nothing" failure the capability flags exist to prevent, and the reason
the flag was held back until the MSI existed to satisfy it.

Linux and macOS keep their compile-time answer.

cc

crates/qbz-qt/Cargo.toml

@@ -186,7 +186,12 @@ winresource = "0.1"
 # SetCurrentProcessExplicitAppUserModelID: the identity Windows groups the
 # taskbar button under and matches a toast's app_id against. 0.61 is already
 # in the workspace lock.
-windows-sys = { version = "0.61", features = ["Win32_UI_Shell"] }
+windows-sys = { version = "0.61", features = [
+  "Win32_UI_Shell",
+  # RegGetValueW: is this install's AppUserModelID actually registered?
+  # Without that, Windows silently drops every toast.
+  "Win32_System_Registry",
+] }
 
 [target.'cfg(target_os = "macos")'.dependencies]
 # DIRECT objc2, added 2026-08-05 for the menu-bar tray: `declare_class!`,