fix: restore repeat button when player controls arrive late

[mvanhorn]

Summary

The fallback observer now records whether left controls were already known before each mutation batch. If that batch is the one that first discovers them, it calls playerRepeatButton() once, before the observer disconnects. Later mutations, including the button's own insertion, do not call it again, so an existing button is not duplicated or reset. A unit test drives that observer with late, nested, and same-batch control nodes and checks the disabled-setting and already-present cases.

Testing

• New unit test: tests/unit/player-repeat-button.test.js.
• npx jest tests/unit/player-repeat-button.test.js: 9 passed.
• npm test: 28 suites, 138 tests passed.

Why

With the repeat control enabled, the button is missing from the player after a full document load: refresh, a restored tab, a pasted URL, a link from outside YouTube, or Back from another site. It does appear on in-site navigation and after the setting is toggled or another video is opened and returned to, and it stays until the next refresh. playerRepeatButton() returns without inserting anything until the player's left controls exist. On a cold load that first call happens before those controls are in the DOM, so it no-ops. The movie-player fallback MutationObserver later finds the controls but never called playerRepeatButton() again, and it disconnects as soon as left controls, right controls, the thumbnail, and the subtitles button are all present, so the missed setup is not retried. In-site navigation and a settings change call the function again after the controls exist, which is why the button shows up then.

Fixes #2755