fix(archives): write a real timestamp on restored photos (#1257)

Brings this branch in line with main, which fixed it in passing.

The archive restore inserted photos with a bare Date for uploaded_at. Inside
jest the sqlite3 binding's type dispatch misses sandbox-created Dates and
stores the literal string "[object Object]", so every restored photo got a
garbage timestamp. Verified on this branch rather than assumed:

  bare Date   -> "[object Object]"
  toISOString -> "2026-09-01T06:48:41.915Z"

Production writes Dates as ms-numbers and is unaffected, which is exactly why
it survives unnoticed — it only corrupts what tests read back, so a future
test asserting on a restored photo's date would have believed it.

The regression test fails against the previous line.

Not touched: the category insert a few lines up has the same shape, but it is
identical on main, so fixing it here alone would re-open the divergence this
commit closes. Worth one small PR against both branches.

Co-authored-by: Paul Nothaft <[email protected]>

backend/src/routes/adminArchives.js

@@ -464,7 +464,13 @@ router.post('/:id/restore', adminAuth, requirePermission('archives.restore'), re
                 type: path.extname(filename).substring(1).toLowerCase(),
                 size_bytes: stats.size,
                 category_id: categoryId,
-                uploaded_at: new Date()
+                // .toISOString(), not a Date: inside jest the sqlite3 binding's
+                // type dispatch misses sandbox-created Dates and stores the
+                // literal string "[object Object]", so every restored photo
+                // gets a garbage timestamp that any test reading it would
+                // believe. Production stores Dates as ms-numbers and is
+                // unaffected — which is exactly why this survives unnoticed.
+                uploaded_at: new Date().toISOString()
               });
             }
           } catch (statError) {