Add backlog tasks and launcher time helper tests

- Track follow-up cleanup work in Backlog.md
- Replace Date.now usage with shared nowMs helper
- Add launcher args/parser and core regression tests

backlog/tasks/task-238 - Codebase-health-follow-up-decompose-remaining-oversized-runtime-surfaces.md

@@ -18,6 +18,8 @@ references:
   - backlog/tasks/task-87 - Codebase-health-harden-verification-and-retire-dead-architecture-identified-in-the-March-2026-review.md
   - backlog/completed/task-87.4 - Runtime-composition-root-remove-dead-symbols-and-tighten-module-boundaries-in-src-main.ts.md
   - backlog/completed/task-87.6 - Anki-integration-maintainability-continue-decomposing-the-oversized-orchestration-layer.md
+  - backlog/tasks/task-238.6 - Extract-remaining-inline-runtime-logic-and-composer-gaps-from-src-main.ts.md
+  - backlog/tasks/task-238.7 - Split-src-main.ts-into-boot-phase-services-runtimes-and-handlers.md
 priority: high
 ---
 
@@ -45,6 +47,8 @@ Recommended sequencing:
 2. Run TASK-238.4 and TASK-238.5 in parallel after TASK-238.3 if desired; they touch different domains.
 3. Run TASK-238.1 after or alongside the domain refactors, but keep it focused on window/bootstrap composition only.
 4. Run TASK-238.2 after TASK-238.1 because both touch `src/main.ts` and the CLI/headless flow should build on the cleaner composition root.
+5. Run TASK-238.6 after the current composer/setup-window-factory work lands, so the remaining inline runtime logic and composer gaps are extracted from the already-cleaned composition root.
+6. Run TASK-238.7 only after TASK-238.6 confirms the remaining entrypoint surface still justifies a boot-phase split; then move the boot wiring into dedicated service/runtime/handler modules.
 
 Shared guardrails:
 

backlog/tasks/task-238.6 - Extract-remaining-inline-runtime-logic-and-composer-gaps-from-src-main.ts.md

@@ -0,0 +1,60 @@
+---
+id: TASK-238.6
+title: Extract remaining inline runtime logic and composer gaps from src/main.ts
+status: To Do
+assignee: []
+created_date: '2026-03-27 00:00'
+labels:
+  - tech-debt
+  - runtime
+  - maintainability
+  - composers
+milestone: m-0
+dependencies:
+  - TASK-238.1
+  - TASK-238.2
+references:
+  - src/main.ts
+  - src/main/runtime/youtube-flow.ts
+  - src/main/runtime/autoplay-ready-gate.ts
+  - src/main/runtime/subtitle-prefetch-init.ts
+  - src/main/runtime/discord-presence-runtime.ts
+  - src/main/overlay-modal-state.ts
+  - src/main/runtime/composers
+parent_task_id: TASK-238
+priority: high
+---
+
+## Description
+
+<!-- SECTION:DESCRIPTION:BEGIN -->
+`src/main.ts` still mixes two concerns: pure dependency wiring and inline runtime logic. The earlier composer extractions reduce the wiring burden, but the file still owns several substantial behavior blocks and a few large inline dependency groupings. This task tracks the next maintainability pass: move the remaining runtime logic into the appropriate domain modules, add missing composer wrappers for the biggest grouped handler blocks, and reassess whether a boot-phase split is still necessary after the entrypoint becomes mostly wiring.
+<!-- SECTION:DESCRIPTION:END -->
+
+## Acceptance Criteria
+
+<!-- AC:BEGIN -->
+- [ ] #1 `runYoutubePlaybackFlow`, `maybeSignalPluginAutoplayReady`, `refreshSubtitlePrefetchFromActiveTrack`, `publishDiscordPresence`, and `handleModalInputStateChange` no longer live as substantial inline logic in `src/main.ts`.
+- [ ] #2 The large subtitle/prefetch, stats startup, and overlay visibility dependency groupings are wrapped behind named composer helpers instead of remaining inline in `src/main.ts`.
+- [ ] #3 `src/main.ts` reads primarily as a boot and lifecycle coordinator, with domain behavior concentrated in named runtime modules.
+- [ ] #4 Focused tests cover the extracted behavior or the new composer surfaces.
+- [ ] #5 The task records whether the remaining size still justifies a boot-phase split or whether that follow-up can wait.
+<!-- AC:END -->
+
+## Implementation Plan
+
+<!-- SECTION:PLAN:BEGIN -->
+Recommended sequence:
+
+1. Let the current composer and `setup-window-factory` work land first so this slice starts from a stable wiring baseline.
+2. Extract the five inline runtime functions into their natural domain modules or direct equivalents.
+3. Add or extend composer helpers for subtitle/prefetch, stats startup, and overlay visibility handler grouping.
+4. Re-scan `src/main.ts` after the extraction and decide whether a boot-phase split is still the right next task.
+5. Verify the extracted behavior with focused tests first, then run the relevant broader runtime gate if the slice crosses startup boundaries.
+
+Guardrails:
+
+- Keep the work behavior-preserving.
+- Prefer moving logic to existing runtime surfaces over creating new giant helper files.
+- Do not expand into unrelated `src/main.ts` cleanup that is already tracked by other TASK-238 slices.
+<!-- SECTION:PLAN:END -->

backlog/tasks/task-238.7 - Split-src-main.ts-into-boot-phase-services-runtimes-and-handlers.md

@@ -0,0 +1,58 @@
+---
+id: TASK-238.7
+title: Split src/main.ts into boot-phase services, runtimes, and handlers
+status: To Do
+assignee: []
+created_date: '2026-03-27 00:00'
+labels:
+  - tech-debt
+  - runtime
+  - maintainability
+  - architecture
+milestone: m-0
+dependencies:
+  - TASK-238.6
+references:
+  - src/main.ts
+  - src/main/boot/services.ts
+  - src/main/boot/runtimes.ts
+  - src/main/boot/handlers.ts
+  - src/main/runtime/composers
+parent_task_id: TASK-238
+priority: high
+---
+
+## Description
+
+<!-- SECTION:DESCRIPTION:BEGIN -->
+After the remaining inline runtime logic and composer gaps are extracted, `src/main.ts` should be split along boot-phase boundaries so the entrypoint stops mixing service construction, domain runtime composition, and handler wiring in one file. This task tracks that structural split: move service instantiation, runtime composition, and handler orchestration into dedicated boot modules, then leave `src/main.ts` as a thin lifecycle coordinator with clear startup-path selection.
+<!-- SECTION:DESCRIPTION:END -->
+
+## Acceptance Criteria
+
+<!-- AC:BEGIN -->
+- [ ] #1 Service instantiation lives in a dedicated boot module instead of a large inline setup block in `src/main.ts`.
+- [ ] #2 Domain runtime composition lives in a dedicated boot module, separate from lifecycle and handler dispatch.
+- [ ] #3 Handler/composer invocation lives in a dedicated boot module, with `src/main.ts` reduced to app lifecycle and startup-path selection.
+- [ ] #4 Existing startup behavior remains unchanged across desktop and headless flows.
+- [ ] #5 Focused tests cover the split surfaces, and the relevant runtime/typecheck gate passes.
+<!-- AC:END -->
+
+## Implementation Plan
+
+<!-- SECTION:PLAN:BEGIN -->
+Recommended sequence:
+
+1. Re-scan `src/main.ts` after TASK-238.6 lands and mark the remaining boot-phase seams by responsibility.
+2. Extract service instantiation into `src/main/boot/services.ts` or equivalent.
+3. Extract runtime composition into `src/main/boot/runtimes.ts` or equivalent.
+4. Extract handler/composer orchestration into `src/main/boot/handlers.ts` or equivalent.
+5. Shrink `src/main.ts` to startup-path selection, app lifecycle hooks, and minimal boot wiring.
+6. Verify the split with focused entrypoint/runtime tests first, then run the broader runtime gate if the refactor crosses startup boundaries.
+
+Guardrails:
+
+- Keep the split behavior-preserving.
+- Prefer small boot modules with narrow ownership over a new monolithic bootstrap layer.
+- Do not reopen the inline logic work already tracked by TASK-238.6 unless a remaining seam truly belongs here.
+<!-- SECTION:PLAN:END -->

backlog/tasks/task-241 - Add-optional-setup-action-to-seed-subminer-mpv-profile.md

@@ -0,0 +1,37 @@
+id: TASK-241
+title: Add optional setup action to seed SubMiner mpv profile
+type: feature
+status: Open
+assignee: []
+created_date: '2026-03-27 11:22'
+updated_date: '2026-03-27 11:22'
+labels:
+  - setup
+  - mpv
+  - docs
+  - ux
+dependencies: []
+references: []
+documentation:
+  - /home/sudacode/projects/japanese/SubMiner/docs-site/usage.md
+  - /home/sudacode/projects/japanese/SubMiner/docs-site/launcher-script.md
+ordinal: 24100
+---
+
+## Description
+
+<!-- SECTION:DESCRIPTION:BEGIN -->
+Add an optional control in the first-run / setup flow to write or update the user’s mpv configuration with SubMiner-recommended defaults (especially the `subminer` profile), so users can recover from a missing profile without manual config editing.
+
+The docs for launcher usage must explicitly state that SubMiner’s Windows mpv launcher path runs mpv with `--profile=subminer` by default.
+<!-- SECTION:DESCRIPTION:END -->
+
+## Acceptance Criteria
+
+<!-- AC:BEGIN -->
+- [ ] #1 Add an optional setup UI action/button to generate or overwrite a user-confirmed mpv config that includes a `subminer` profile.
+- [ ] #2 The action should be non-destructive by default, show diff/contents before write, and support append/update mode when other mpv settings already exist.
+- [ ] #3 Document how to resolve the missing-profile scenario and clearly state that the SubMiner mpv launcher runs with `--profile=subminer` by default (`--launch-mpv` / Windows mpv shortcut path).
+- [ ] #4 Add/adjust setup validation messaging so users are not blocked if `subminer` profile is initially missing, but can opt into one-click setup recovery.
+- [ ] #5 Include a short verification path for both Windows and non-Windows flows (for example dry-run + write path).
+<!-- AC:END -->