test(secrets): pin the once-guard against a late window reveal

The fallback can report first and the window reveal arrive after it; without
the guard that probes the keyring a second time, blocking the main thread just
as the user starts interacting. No existing case covered that order — removing
the guard left all six tests green.

src/main/host/deferred-secret-protection-report.test.ts

@@ -132,6 +132,20 @@ describe('scheduleSecretProtectionGapReport', () => {
     expect(probes).toBe(1)
   })
 
+  it('does not probe again when the window reveals after the fallback already reported', () => {
+    // Why this order and not the reverse: a GPU that presents late reveals the window
+    // after the fallback has already reported, and a second blocking keyring probe would
+    // freeze the main thread exactly as the user starts interacting.
+    schedule()
+    const window = createWindow()
+    vi.advanceTimersByTime(15_100)
+    drain()
+    expect(probes).toBe(1)
+    window.reveal()
+    drain()
+    expect(probes).toBe(1)
+  })
+
   it('reports inline in headless serve, before the runtime is advertised as ready', () => {
     // Why not deferred: serve opens no window, so the fallback would fire only after
     // clients could already have paired, and a frozen main thread reads as a dead host.