fix(ui): hide disabled media browser buttons

[JamBalaya56562]

Summary

• hide the Pictures media browser button when Still pictures are disabled
• hide the Movies media browser button when Movies are disabled
• keep the existing simple MJPEG behavior that hides both media browser buttons

Why

The camera overlay currently exposes media browser buttons even when the corresponding media capture feature is disabled. This makes the top-button state inconsistent with the camera settings.

Fixes #2731.

Validation

• Checked the diff is limited to motioneye/static/js/main.js
• Verified the simple MJPEG media-button behavior remains unchanged
• Could not run pytest in the local environment because pytest is not installed (python3 -m pytest reports No module named pytest)

[Marijn0]

Thanks for working on this. I think the idea of hiding irrelevant buttons makes sense (IMO).

However, I have a concern with the current implementation. The buttons are hidden purely based on whether still images or movies are enabled in the camera configuration, but this doesn't account for existing media files.

Consider this scenario: a user had still images or movies enabled for some time, then disables them. They still have photos and/or movies on disk that they may want to view, download, or delete. With this PR, the buttons would be hidden, leaving them with no way to access those existing files through the UI.

My suggestion would be to hide the button only when both of these conditions are true:

• The corresponding capture mode is disabled (as implemented now).
• There are no existing files of that type.

That way, the button disappears only when it truly serves no purpose.

[JamBalaya56562]

Good point — thanks! Addressed in c154a74.

A media-browser button is now hidden only when its capture mode is disabled and the list endpoint returns no files of that type, so media recorded before disabling capture stays accessible:

• when a mode is disabled, an async …/list/?with_stat=false check runs and the button is hidden only if mediaList comes back empty (the button is left visible on error / while unsure, so there's no flicker for the case that still has media);
• enabled modes issue no request at all;
• simple MJPEG cameras still hide both buttons as before.

One note: this reuses the existing list endpoint, which builds the full media list just to test emptiness (only for disabled-capture cameras). A dedicated lightweight has_media check (early-exit, plus a remote variant) would be cheaper but is a bigger change than this UI tweak — happy to do it as a follow-up if you'd prefer.

[JamBalaya56562]

Heads up: this PR was closed by accident when its branch got deleted during a rebase. The work continues in #3387, which carries the same change plus the review fix @Marijn0 requested here (hide a media button only when its capture mode is disabled and there are no existing files of that type). Please follow #3387 — sorry for the noise!