feat(notifications): add overlay notifications with position config (#110)

docs/architecture/subtitle-overlay-priming.md

@@ -64,6 +64,25 @@ prefetch work and re-centers prefetch around the live playback time.
 - If secondary `requestProperty` fails, the primary flow stays complete and only a debug line is
   written.
 
+## Startup Ready Release
+
+- `mpv.pauseUntilOverlayReady` waits for tokenization warmup plus visible-overlay readiness before
+  releasing the mpv startup gate.
+- Visible-overlay startup creates the tray and visible overlay shell before tokenization and
+  annotation warmups continue. Cold `--start --background --managed-playback` launches still handle
+  initial args before the deferred Yomitan wait.
+- Overlay-routed startup notifications are queued in the main process until an overlay window has
+  finished loading. Progress notifications with the same id are upserted so spinner ticks do not
+  flood a cold-start overlay, while events with distinct history ids are retained for phase-level
+  history such as character dictionary checking/building/importing.
+- The mpv plugin has a 30-second fallback for cold starts; app-side retry/release budgets match that
+  window so readiness can still arrive before fallback resumes playback.
+- If mpv is already on a subtitle, SubMiner still prefers the resolved current subtitle payload and
+  waits for a fresh measured subtitle rectangle before signaling readiness.
+- If mpv is before the first subtitle, SubMiner sends a synthetic warm readiness payload after
+  tokenization warmup and visible overlay content-ready. This releases playback without waiting for
+  a later subtitle event that cannot happen while mpv is paused.
+
 ## Linux/X11 Window Shape
 
 - `restoreLinuxOverlayWindowShape()` reads `BrowserWindow.getBounds()` and calls `setShape()` with

docs/plans/2026-06-06-early-managed-overlay-startup-design.md

@@ -0,0 +1,29 @@
+<!-- read_when: changing managed mpv startup, pause-until-ready, or visible overlay boot ordering -->
+
+# Early Managed Overlay Startup Design
+
+Status: approved
+Date: 2026-06-06
+
+## Problem
+
+Managed mpv startup can pause playback immediately, then leave SubMiner's tray and visible overlay
+unavailable until Yomitan/tokenization warmups finish. Startup notifications therefore miss the
+overlay surface and fall back to non-overlay status paths.
+
+## Chosen Approach
+
+For cold `--start --background --managed-playback` launches, handle initial args before waiting for
+the deferred overlay warmup. That lets the tray and visible overlay shell initialize immediately
+while the existing tokenization warmups continue in the background.
+
+The mpv plugin pause gate stays armed. Playback release still waits for SubMiner's autoplay-ready
+signal, which is emitted only after tokenization warmup and visible-overlay readiness. Existing
+second-instance attach behavior remains unchanged: when the launcher finds an already-running
+background app, it sends the same control command to that process and reuses its warmups/tokenizer.
+
+## Checks
+
+- Add a startup ordering regression test for managed background playback.
+- Keep the existing deferred startup ordering for non-managed launches.
+- Run the startup/runtime test slice plus SubMiner verification lane.

docs/plans/2026-06-09-macos-notification-hover-design.md

@@ -0,0 +1,27 @@
+<!-- read_when: changing overlay notification hover, macOS mouse passthrough, or notification actions -->
+
+# macOS Notification Hover Stability Design
+
+Status: approved
+Date: 2026-06-09
+
+## Problem
+
+On macOS, hovering a character dictionary build notification can make the card flicker and slide as
+if it is hiding, then snap back. The likely trigger is the notification stack changing the overlay
+window's mouse-passthrough state for a progress card that has no user action.
+
+## Chosen Approach
+
+Keep non-action overlay notifications visually stable and click-through on hover. Only notifications
+with explicit actions should request interactive overlay input. The notification history panel keeps
+its existing interactive behavior.
+
+This avoids a macOS mouseenter/mouseleave passthrough loop for passive progress cards while
+preserving clickable notification actions.
+
+## Checks
+
+- Add a renderer regression test for passive notification hover.
+- Keep action-bearing notification cards interactive.
+- Run the targeted overlay notification and mouse-ignore tests.