fix: unblock desktop confirm dialogs (#512)

Tauri's desktop webview injects window.confirm through the dialog confirm command, but the default desktop capability only allowed the message dialog command. Windows release builds could therefore reject confirm at ACL time even though the browser-facing code path looked valid in local web development.

Constraint: Tauri plugin-dialog 2.7 still exposes window.confirm as plugin:dialog|confirm in the injected webview shim.
Rejected: Grant dialog:default | broader than the specific confirm compatibility gap.
Confidence: high
Scope-risk: narrow
Directive: Keep confirm permission covered while the desktop webview exposes browser confirm shims.
Tested: cd desktop && bun run test -- --run src/__tests__/tauriCapabilities.test.ts
Tested: bun run check:desktop
Tested: bun run check:native
Not-tested: Windows release package manual smoke

desktop/src-tauri/capabilities/default.json

@@ -101,6 +101,7 @@
     "dialog:allow-open",
     "dialog:allow-save",
     "dialog:allow-message",
+    "dialog:allow-confirm",
     "notification:default",
     "process:allow-exit",
     "process:allow-restart",

desktop/src/__tests__/tauriCapabilities.test.ts

@@ -22,6 +22,16 @@ describe('Tauri default capability', () => {
     ).toBe(true)
   })
 
+  it('allows the browser confirm shim used by the desktop webview', () => {
+    const permissions = readDefaultCapabilityPermissions()
+
+    expect(
+      permissions.some(permission =>
+        permission === 'dialog:default' || permission === 'dialog:allow-confirm'
+      )
+    ).toBe(true)
+  })
+
   it('keeps file dialog access enabled', () => {
     const permissions = readDefaultCapabilityPermissions()