fix(extension): import the best-quality Twitter video variant

[abhay-codes07]

Problem

When importing bookmarked tweets, the video URL was taken as video_info.variants[0].url:

const videos = media
  .filter((m) => m.type === "video")
  .map((m) => ({
    url: m.video_info?.variants?.[0]?.url || "",
    ...
  }))

Twitter returns several variants for a single video: an HLS .m3u8 playlist (which has no bitrate and is not a directly usable video file) plus multiple video/mp4 renditions at different bitrates, in no guaranteed order. So variants[0] frequently stored either the HLS playlist URL or whatever low-bitrate rendition happened to be first, rather than a good, directly-playable MP4.

The variant type also didn't model bitrate / content_type at all, so there was nothing to select on.

Fix

Add a small pure helper and use it at the call site:

export function pickBestVideoVariantUrl(variants: VideoVariant[] | undefined): string {
  if (!variants || variants.length === 0) return ""
  const mp4s = variants.filter(
    (v) => v.content_type === "video/mp4" || /\.mp4(?:\?|$)/i.test(v.url),
  )
  const pool = mp4s.length > 0 ? mp4s : variants
  let best = pool[0]
  for (const variant of pool) {
    if ((variant.bitrate ?? 0) > (best?.bitrate ?? 0)) best = variant
  }
  return best?.url || ""
}

It prefers MP4 renditions (by content_type, or by a .mp4 URL when content_type is absent), picks the highest bitrate among them, and falls back to the first variant when there is no MP4 (e.g. HLS-only), which preserves the old behaviour in that degenerate case. The VideoVariant type now includes the bitrate / content_type fields the API actually returns.

Tests

twitter-video-variant.test.ts (bun:test): highest-bitrate MP4 wins over first/lower entries, the HLS playlist is never chosen when MP4s exist, MP4 is detected by extension when content_type is missing, HLS-only falls back to the first variant, and empty/undefined returns "". 5 tests pass; extension tsc is clean for this file.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.