Heavy load time on Safari for Scene pages

Have you enabled troubleshooting mode?

• I confirm that the troubleshooting mode is enabled.

Describe the bug

I've noticed since I switched from Chrome to Safari that the scene page operated insanely slower and hadn't had time to dig into it so I had just been keeping my page size at the smallest. I did some experimenting download HARs to compare, recording page timelines, and looking at layers and passing that all into Claude to help me sort through and test against.

If I put it to the extreme and put 1000 scene page sizes, Chrome loaded it in 2s no sweat, Safari would hang after everything but the thumbnails had loaded and wouldn't become responsive again and load them in till after 215s which is an insane difference.

There are a few layers to why this happens:

1. Every card renders a <video> element parked offscreen. The IntersectionObserver on hover moves the video into view and play() runs. On mouse-out the video moves off-screen and pause() runs. BUT because IntersectionObserver always delivers an initial callback when observe() is called on page load every video off-screen receives a pause() call. In WebKit pause() on a a media element that has a src starts the media player setup so it starts setting up the full media player for 1000 cards all at once.
2. Another small WebKit cost as well is that even without the call each <video> element with a src costs some player/compisiting work.

Steps to reproduce

1. Open Stash in Safari with a large library with video previews generated
2. Go to the scenes page
3. For seeing the extreme set the page size to 1000 but you will see freeze ups on smaller page sizes too

Expected behaviour

I would expect this page to be load even 1000s scene cards in at most 10s on good internet connection to the server.

Screenshots or additional context

I'm not sure when I'll have time to properly write this out myself but I have Claude throw together a plugin for me that brought the page load time on 1000 scenes all the way down to 0.4s. Here is that gist as a proof of concept that should help with any fixes if someone else wants to tackle it https://gist.github.com/mmenanno/633292fef7989a73177f1c54bdf1c3dc

The solutions it applied were to:

1. Prevent that initial pause() call to every video on page load (this got me down to about a 6s load)
2. Don't attach the src to the video until it is hovered over (this got me down to 0.4s)

There is technically another fix I threw on in the mix that helped me originally get down to 115s but doesn't make a difference really once the above changes are applied. That was appling this custom CSS that was fixing the fact that all the scene cards have a "hacky" application being applied offscreen a -99999 index so Safari was also spending time preparing all those layers, but hiding their visibility prevents that:

.scene-card .scene-card-preview-video,
.scene-marker-card .scene-card-preview-video {
  display: none;
}
.scene-card:hover .scene-card-preview-video,
.scene-card:active .scene-card-preview-video,
.scene-marker-card:hover .scene-card-preview-video,
.scene-marker-card:active .scene-card-preview-video {
  display: block;
}

Stash version

v0.31.1-167-gb872e360

Device details

Safari 26.6.2 on macOS 26.6.2

Relevant log output