[Enhancement] Files/photos (re-run): Bulk file upload accepts .zip but never extracts it

Area: Files/photos (re-run) (audit p5r) · Surface: /files/{slug}/bulk-upload (FileController@storeBulkUpload) · Dimension: existing-feature-improvement · Severity: minor

An admin seeding a retro-computing area typically has a folder of 300 disk images. Today bulk upload helps, but if they drop a single zip of those images it lands as one undownloadable-as-collection archive rather than 300 catalogued files. Competitors that target content libraries (and the DiskImageReader we already ship for .d64 listings) make 'drop a zip, we unpack and catalog each file' the headline bulk-import flow. We already have ClamAV scanning and per-file metadata extraction in the pipeline; unpacking the zip first would multiply the value of bulk upload for exactly the power users who build these archives.

Evidence

The bulk-upload dropzone accepts archives: `accept=".zip,.rar,.7z,.tar,.gz,..."` (templates/files/bulk-upload.php:40), and storeBulkUpload simply stores each file as-is — there is no ZipArchive/extract logic (grep for zip|extract|ZipArchive in the template shows only the accept attr and breadcrumb icon; the controller path at FileController.php:1300-1463 stores each upload verbatim).

Suggested fix. In storeBulkUpload, when an entry is a zip, expand it server-side (with entry-count/size limits + per-entry extension + ClamAV checks), create one file_uploads row per safe entry, and skip the zip itself. Keep the existing per-file path for non-archives.

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.