[Feature] Persist buffered videos to storage with configurable retention (avoid re-download after refresh)

[ramhaidar]

Description:
Is your feature request related to a problem? Please describe.
Currently, buffered video data appears to live only in memory/session. When the page is refreshed (or the tab/browser is closed and reopened), the buffer is lost and the video needs to be downloaded again. This hurts UX (especially on slow/expensive connections) and increases bandwidth usage and load time.

Describe the solution you'd like
Add an option to persist buffered video chunks to client-side storage so that:

• After a page refresh / reopen, previously buffered content can be loaded again and playback can resume without re-downloading the same data (at least for the already-buffered parts).
• Default retention is ~7 days (auto-delete cached items older than the configured TTL).
• Retention is configurable by the user (e.g., 1-30 days, or disable persistence).
• Include automatic cleanup (garbage collection) for expired entries, and ideally an optional max cache size / eviction strategy to avoid unbounded storage growth.

Possible implementation direction (flexible):

• Use a storage suitable for blobs/chunks (e.g., IndexedDB and/or Cache Storage).
• Store metadata per entry (key/url, createdAt/lastAccessed, size, retentionDays, cacheVersion).
• On video request, check persistent cache first; if present and not expired, serve from cache; otherwise fall back to network download as today.
• Support invalidation when URL/signature changes or cache format/version changes.

Describe alternatives you've considered

• Relying on default browser HTTP caching / service workers alone, but it may not provide reliable chunk-level reuse and the retention/eviction controls needed.
• Keeping only an in-memory buffer (current behavior), but it is lost on refresh.
• Providing a manual "offline download" feature, which is different from the goal of automatically reusing buffered data.

Additional context
Primary use cases:

• Frequent refreshes during dev/testing or accidental reloads where users expect fast resume.
• Reduce redundant bandwidth usage and improve resume/startup time.
  Notes/considerations:
• Browser storage quotas vary; eviction policy (LRU and/or expired-first) may be needed.
• Privacy: cache should be origin-scoped and easy for users to clear.