Dated Folders fail to play video in sidebar.

ComfyUI version: v0.30.2
Frontend package: comfyui-frontend-package 1.47.12
OS: Windows 11
Browsers affected: Firefox 153 (explicit error), Chromium-based browsers (silent -- video area just stays blank)

Summary:
Videos saved into a dated subfolder (e.g. via a filename_prefix containing a date template like %date:yyyy-MM-dd%/ComfyUI) fail to play in the sidebar Assets/gallery panel, even though the same output plays fine when opened from its own job's detail view. The request the gallery issues for the video omits the subfolder query parameter, even though the job data it was built from has the correct subfolder -- so the backend can't find the file and returns 204, which browsers report as an unsupported/missing format.

Steps to reproduce:
1. Use a node that saves a video with a non-empty output subfolder (e.g. VHS_VideoCombine from ComfyUI-VideoHelperSuite with filename_prefix = %date:yyyy-MM-dd%/ComfyUI).
2. Queue the workflow; confirm the file lands in output//.mp4.
3. Open the sidebar Assets/gallery panel and try to play that video.
4. Compare with opening the same job from history and playing the video there (works).

Expected:
Video plays in the Assets panel, same as it does from the job's own detail view.

Actual:
Firefox: reports "No video with supported format or MIME type found."
Chromium: video area stays blank with no visible error.

Network trace shows the actual failing request:

GET /api/viewvideo?filename=ComfyUI_00035_.mp4&type=output&subfolder=
-> 204 No Content

taken moments after this API response, which has the correct subfolder:

{"jobs": [{"id": "deed8756-...", "status": "completed", ...,
"preview_output": {"filename": "ComfyUI_00035_.mp4", "subfolder": "2026-08-07", "type": "output", "nodeId": "92", "mediaType": "images"},
"workflow_id": "..."}], ...}

The request should have included subfolder=2026-08-07; because it didn't, the server (correctly, per its own logic) can't locate the file and returns 204 -- an empty body, which is why the element has nothing to sniff a format from.

Where it looks like the bug is:
In the frontend bundle (assets/settingStore-*.js), the view-model used by the shared video-preview component:

ResultItemImpl = class {
constructor(e) {
this.filename = e.filename ?? '';
this.subfolder = e.subfolder ?? '';
this.type = e.type ?? '';
...
}
get urlParams() {
let e = new URLSearchParams();
e.set('filename', this.filename);
e.set('type', this.type);
e.set('subfolder', this.subfolder); // correctly included IF this.subfolder is non-empty
...
return e;
}
get url() { return this.filename ? apiURL('/view?' + this.urlParams) : ''; }
get vhsAdvancedPreviewUrl() { return apiURL('/viewvideo?' + this.urlParams); }
}

and the shared ResultVideo component that picks between the two:

ResultVideo = { setup(e) {
const useAdvanced = computed(() =>
isExtensionInstalled('VideoHelperSuite.Core') &&
isExtensionEnabled('VideoHelperSuite.Core') &&
settings.get('VHS.AdvancedPreviews') &&
settings.get('VHS.AdvancedPreviews') !== 'Never'
);
const src = computed(() => useAdvanced.value ? e.result.vhsAdvancedPreviewUrl : e.result.url);
...
}}

urlParams itself handles subfolder correctly -- the bug is upstream, in whatever constructs the e object passed into new ResultItemImpl(e) for the Assets/gallery panel's compact per-job listing. That code isn't carrying the subfolder value from the preview_output it's fed (see the /api/jobs response above, which has the correct value), even though the same subfolder is correctly used elsewhere (e.g. the job's own detail-view preview, which plays fine).

Since ResultVideo reroutes through VHS.AdvancedPreviews (default "Input Only", i.e. not "Never") whenever VideoHelperSuite is installed, this bug is easy to mistake for a VideoHelperSuite issue -- it isn't; VideoHelperSuite's own /viewvideo endpoint (and core's own /view) both correctly 204 given an empty subfolder for a file that isn't actually there. Setting VHS.AdvancedPreviews to "Never" avoids the /viewvideo hop but the same ResultItemImpl.subfolder value likely still feeds the fallback /view request, so it may not fully resolve the issue either -- the real fix needs to happen wherever the Assets/gallery panel builds its ResultItemImpl instances from job/asset data.

Suggested fix:
Ensure the code that maps a job's output/preview summary into ResultItemImpl (or whatever feeds the Assets/gallery panel specifically) passes through subfolder the same way the job-detail-view path already does.

Start in the frontend bundle entry points mentioned in assets/settingStore-*.js, tracing the Assets/gallery mapping into ResultItemImpl and the shared ResultVideo component. Compare that path with the job-detail preview and the /api/jobs preview_output data, then reproduce with a dated output folder. Done means the gallery request includes the subfolder and the video plays in both Firefox and Chromium.

Written by the indexing model from the issue text.