Generate real resized thumbnails for image attachments (#98)

The attachment grid's <img> thumbnail pointed at the same
download_attachment.php URL as the full-size original, so previewing a
multi-MB photo attachment cost a full multi-MB download just to render a
small grid preview. loading="lazy" only deferred off-screen images; it
never reduced per-image transfer size.

Generate a resized JPEG thumbnail (longest side capped at 300px) via GD
at upload time, from the same metadata-stripped image stripImageMetadata()
already produces, reusing its decompression-bomb guard (~40MP decode cap).
Store the thumbnail's filename in a new nullable ticket_attachments.
thumbnail_filename column (migration 005); NULL means no thumbnail exists
(non-image, GD unavailable, or an attachment predating this change) and
callers fall back to the full-size original.

download_attachment.php serves the thumbnail when requested via
?thumb=1 and one exists, falling back to the original otherwise. The
attachments grid now requests thumb=1 for its <img> preview; the
lightbox link is unchanged and still opens the full-size original.
delete_attachment.php removes the thumbnail file alongside the original,
and cleanup_orphan_uploads.php's orphan lookup now also matches
thumbnail_filename so generated thumbnails aren't swept up as orphans.

Verified against real MariaDB + GD: a 1600x1200 test JPEG produced a
300x225 thumbnail at ~1.8KB vs. the 52KB original (~29x smaller);
confirmed the serving logic picks the thumbnail for image attachments
with one, falls back to the original for a non-image attachment even
when thumb=1 is requested, and that the updated orphan-cleanup lookup
matches both the original and thumbnail filename (and correctly finds
neither for an unrelated filename).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0117oBw2jN4kALYeS8HPq4zV

scripts/cleanup_orphan_uploads.php

@@ -59,10 +59,11 @@ try {
     exit(1);
 }
 
-// Prepared lookup: does any attachment row reference this stored filename?
-// Stored filenames are globally unique (uniqid), so filename alone is sufficient
-// and safe — a match in any ticket means the file is a real attachment.
-$lookup = $conn->prepare('SELECT 1 FROM ticket_attachments WHERE filename = ? LIMIT 1');
+// Prepared lookup: does any attachment row reference this stored filename,
+// either as the original file or as its generated preview thumbnail? Both
+// are globally unique (uniqid-derived), so filename alone is sufficient and
+// safe — a match in any ticket means the file is a real, referenced file.
+$lookup = $conn->prepare('SELECT 1 FROM ticket_attachments WHERE filename = ? OR thumbnail_filename = ? LIMIT 1');
 if ($lookup === false) {
     logMessage('FATAL ERROR: could not prepare lookup statement: ' . $conn->error);
     exit(1);
@@ -101,8 +102,9 @@ foreach (new DirectoryIterator($uploadRoot) as $entry) {
             continue;
         }
 
-        // Keep the file if any attachment row references it.
-        $lookup->bind_param('s', $filename);
+        // Keep the file if any attachment row references it (as the
+        // original or as its thumbnail).
+        $lookup->bind_param('ss', $filename, $filename);
         $lookup->execute();
         $hasRow = $lookup->get_result()->num_rows > 0;