feat: Add Adaptive Buffer-Aware Quality Manager (#3967)

[Bhaumik1904]

Closes #3967

What this does

Implements an alternative to the "Smart Buffer Management" feature requested in #3967.

After feasibility analysis, direct buffer eviction (SourceBuffer.remove()) was confirmed impossible from a browser extension — YouTube owns its MediaSource pipeline internally and does not expose it.

This PR implements the only viable alternative: a quality manager that monitors how many seconds are buffered ahead of the playhead, and temporarily lowers stream quality when it exceeds a configurable ceiling. This prevents unbounded RAM growth on long videos by slowing down YouTube's buffering — the only lever an extension can actually control.

Changes

• player.js — New ImprovedTube.smartBufferManager() function
• functions.js — Hooked into initPlayer() and playerOnTimeUpdate()
• core.js — Live-toggle support via case 'smartBuffer':
• menu/skeleton-parts/player.js — Settings UI (toggle + slider, 30–600s, default 120s)
• _locales/en/messages.json — English strings added (translations welcome from contributors)

How it works

1. Every 500ms (on the existing timeupdate heartbeat), reads video.buffered
2. If buffered-ahead > ceiling → lowers quality to 480p
3. If buffered-ahead drops below 60% of ceiling → restores original quality
4. Skips live streams and paused video automatically
5. Instant on/off from the popup via the storage-changed handler

[communism420]

Thank you for your work!

[communism420]

Why my approval doesn't merge everything automatically?

[wahajahmed010]

Review: Adaptive Buffer-Aware Quality Manager

Overall: Clever approach to a hard problem. The analysis that direct buffer eviction is impossible from an extension is correct, and the quality-throttling alternative is pragmatic.

Good

• Hysteresis band (restore at 60% of ceiling) prevents oscillation
• Guards for paused, live streams, and missing metadata are all correct
• Cleanup path when feature is toggled off restores original quality
• Uses playerQuality() which respects existing quality selection infrastructure

Concerns

1. playerQuality(large) hardcodes 480p — May be too aggressive. On a 4K monitor, 480p looks noticeably bad. Consider making throttle quality configurable.
2. Called on every 500ms tick — Runs ~14,400 times for a 2hr video. Once throttled, skip checks for N seconds since buffer won't drain instantly.
3. Stale quality on manual change — If user manually changes quality while throttled, _sbmQualityBeforeThrottle could be stale. Consider resetting throttle state on manual quality change.

Nit

• Comment says large = 480p but YouTube quality labels vary. A comment referencing the actual itag would be more precise.

Verdict: No blocking issues. Approach is sound for an extension-level workaround.