feat: add configurable double-tap seek distances

[luckyKingdog]

Summary

• add a configurable touchscreen double-tap seek handler for default, fixed, and progressive modes
• use the YouTube player seekBy API first, with a seekTo/currentTime fallback, while leaving native behavior untouched in default mode
• expose fixed and progressive seek controls in the Player menu with English labels

Verification

• npm test -- tests/unit/double-tap-seek.test.js
• npm run lint

Closes #4132

[luckyKingdog]

Follow-up update for the #4132 implementation notes:

• Routed the touchend listener through shortcuts.js instead of player.js.
• Removed the extra player.js / video init wiring from the PR surface.
• Kept default/native mode untouched, and custom modes now use player.seekTo(targetTime, true) first with seekBy only as a fallback.
• Kept the ytp-seek-forward-bump / ytp-seek-backward-bump visual class handling.

Verified locally with npm test -- tests/unit/double-tap-seek.test.js and npm run lint.

[wahajahmed010]

Review: youtube#4136 — Configurable double-tap seek distances

Logic: ✅ Solid implementation. The double-tap detection (500ms window, side tracking, tap counting) is well thought out. The progressive mode with configurable per-tap distances is a nice UX touch.

Edge cases handled well:

• Excludes ad-showing state
• Excludes UI elements (progress bar, settings menu, buttons, inputs)
• Middle zone (35-65% of player width) is a dead zone — prevents accidental seeks when tapping center
• Falls back gracefully when player.getCurrentTime or player.seekTo aren't available
• Bounds target time to [0, duration]

Concerns:

1. event.stopImmediatePropagation() — This is aggressive. It prevents any other touchend handlers from running, including YouTube's native double-tap. If the user has the feature set to 'default' mode, the code returns early (line: if (!mode || mode === 'default'), so this is fine. But in 'fixed' or 'progressive' mode, YouTube's native seek is completely suppressed. This is intentional but worth documenting in the PR description.

2. player_double_tap_seek_seconds slider max is 60 — Seeking 60s on a single double-tap is a lot. Consider if this should be capped lower (30s?) or if the UI should warn. Not a blocker, just a UX note.

3. doubleTapSeekFeedback — The 650ms timeout for removing seek feedback classes is hardcoded. If YouTube ever changes their animation timing, this could desync. Consider tying it to a CSS animationend event instead.

4. Missing test coverage — The PR description mentions npm test -- tests/unit/double-tap-seek.test.js but I don't see a test file in the diff. Was this added in a separate commit or is it missing?

Performance: ✅ No issues. The touch handler is lightweight, DOM queries are minimal, and the state object is small.

Verdict: Well-structured feature. The stopImmediatePropagation concern is the main thing to flag. Otherwise looks good.