fix(speed): preserve native rate when extension has no authoritative target

[rdavidwu]

Summary

Fixes a bug where Chrome's native HTML5 playback-speed control gets silently undone when the extension is loaded.

Reproduction (current behavior):

1. Open a plain <video> page with the extension installed (e.g., w3schools video sample) on a fresh browser session — lastSpeed=null, no per-site rule, rememberSpeed=off.
2. Right-click → Show controls → three-dot menu → Playback speed → 1.5x. Video plays at 1.5x.
3. Click pause, then play. Or scrub the timeline.
4. Bug: speed silently drops to 1.0 while the native menu still shows 1.5x.

Root cause: When lastSpeed === null and no siteDefaultSpeed rule applies, getTargetSpeed() returns the 1.0 baseline as a fallback. Lifecycle handlers (mediaEventAction on play/seeked, and initializeSpeed's deferred loadedmetadata handler) then call adjustSpeed(video, 1.0, init), force-overwriting whatever rate the user set via native controls.

Fix: Add an early-return guard at the top of mediaEventAction and initializeSpeed: when the extension has no authoritative target (lastSpeed null AND siteDefaultSpeed unset), do nothing. The video keeps whatever rate it has. This preserves the null = no opinion invariant established by 12a4fcd end-to-end.

The fix targets the lifecycle restore path rather than trying to detect user gestures upstream — gesture-detection in event-manager.js would require a DOM click to reach document during Chrome's native context-menu flow, which isn't guaranteed (clicks dispatch in browser chrome) and would also widen the trust boundary in ways that could regress 12a4fcd's protection against autonomous site rate changes (ad transitions, stream switches).

Test Coverage

                    mediaEventAction(event) / initializeSpeed()
                              │
                              ▼
              ┌───────────────────────────────┐
              │ lastSpeed === null  &&        │  ← NEW guard
              │ siteDefaultSpeed null/undef ? │
              └──────────────┬────────────────┘
                  TRUE       │       FALSE
            ┌───────────────┘└────────────────┐
            ▼                                  ▼
    [debug log + return]              getTargetSpeed(...)
    native rate preserved              adjustSpeed(...) (existing)
            │                                  │
   ┌────────┼────────┐                ┌────────┴──────────┐
   ▼        ▼        ▼                ▼                   ▼
  play    seeked   loadedmd       lastSpeed set      site rule set
   │        │        │                │                   │
  [T1]    [T2]     [T3]           [#1494]         [event-manager.js]
   ✓        ✓        ✓                ✓                   ✓

Three new tests in tests/unit/core/video-controller.test.js:

• play event is no-op when lastSpeed is null and no per-site rule
• seeked event is no-op when lastSpeed is null and no per-site rule
• initializeSpeed is no-op when lastSpeed is null and no per-site rule (deferred init path)

Existing tests unchanged and still passing:

• play event restore does not overwrite lastSpeed (#1494) — verified the guard does NOT fire when lastSpeed is set, so the Regression: keyboard s/d shortcuts use 1.0x baseline after tab backgrounding #1494 background-tab restore behavior is preserved.
• tests/unit/utils/event-manager.test.js:351-441 — user-gesture window tests for lastSpeed=1.5 paths. No event-manager.js change in this PR.

Tests: 377 → 378 (+1 for the deferred-init regression). All 378 vitest tests pass.

Manual verification

1. npm run build and load dist/ unpacked in Chrome.
2. Open https://www.w3schools.com/html/html5_video.asp (or any plain <video> page) with lastSpeed=null and rememberSpeed=off.
3. Native context menu → Playback speed → 1.5x. Video plays at 1.5x.
4. Click pause then play, then scrub the timeline. Expected: rate stays 1.5x. (Without this fix: drops to 1.0.)
5. Repeat with rememberSpeed on (lastSpeed previously set to 1.8): the existing Regression: keyboard s/d shortcuts use 1.0x baseline after tab backgrounding #1494 behavior is preserved — rate is restored to 1.8 on play even after a background-tab reset.

Test plan

• All 378 vitest unit/integration tests pass (npx vitest run)
• ESLint clean (npx eslint src/)
• Manual reproduction confirms native speed change persists across pause/play/seek
• Regression: keyboard s/d shortcuts use 1.0x baseline after tab backgrounding #1494 regression behavior preserved when lastSpeed is set

🤖 Generated with Claude Code