Phase 5 hygiene: image ownership, real deletes, scan resilience

Images were readable by any signed-in user, not just their owner. Keys
are now namespaced per user in both shapes the app writes, the three
bar/ objects that predated that were migrated under the owner's prefix,
and the image route enforces the prefix - answering 404 rather than 403
so it does not confirm someone else's key exists. Barcode-mirrored
images now write under the user prefix too.

deleteImage existed but was never called, so deleting a drink, bar item
or scan removed the row and left the file in storage forever, still
fetchable. All three now clean up through one shared helper, after the
database work and best-effort, so a storage hiccup cannot block a delete
the user asked for or leave the row behind.

Menu scans are processed detached from the request, so every deploy
abandoned anything in flight and left the row PROCESSING forever with a
spinner that never resolved. They are now reaped lazily when a user
lists their scans - no scheduler needed. Concurrent extractions are
capped at two per process: each is a vision call with a four minute
timeout that costs real money, and nothing else bounded them.

MenuItem gains userId. Ownership was only ever transitive via scanId,
which held because nothing queries MenuItem directly, but left any
future direct query an IDOR with nothing to stop it.

Restore was correctly scoped but unbounded, so a crafted file could
create unlimited rows in one transaction against shared Postgres - self
harm with one user, denial of service with several. Capped, and imageUrl
from the CSV now goes through the same validation the API enforces
instead of reaching the column unchecked.

Members can delete their own account and data. Once the app holds other
people's history, including Rating.location, that is the minimum.

Registration rate limiting took the first x-forwarded-for hop, which the
client controls; it now takes the last, which our proxy appends.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/lib/scan-health.ts

@@ -0,0 +1,60 @@
+import { prisma } from "@/lib/prisma"
+
+/**
+ * Menu scans are processed detached from the request, so a restart - which every
+ * deploy causes - abandons anything in flight and leaves the row PROCESSING
+ * forever, with a spinner that never resolves.
+ *
+ * There is no job queue to recover them, so instead they are reaped lazily whenever
+ * a user looks at their scans. Cheap, needs no scheduler, and the worst case is a
+ * stuck scan showing as failed a little later than it truly failed.
+ */
+const STUCK_AFTER_MS = 15 * 60 * 1000
+
+export async function reapStuckScans(userId: string): Promise<number> {
+  try {
+    const { count } = await prisma.menuScan.updateMany({
+      where: {
+        userId,
+        status: "PROCESSING",
+        updatedAt: { lt: new Date(Date.now() - STUCK_AFTER_MS) },
+      },
+      data: {
+        status: "FAILED",
+        errorMessage: "Processing was interrupted. Please try scanning again.",
+      },
+    })
+    if (count > 0) {
+      console.warn(`[scan] reaped ${count} stuck scan(s) for ${userId}`)
+    }
+    return count
+  } catch (error) {
+    // Never let housekeeping break a page load.
+    console.warn("[scan] reap failed:", error)
+    return 0
+  }
+}
+
+/**
+ * Caps concurrent menu extractions in this process.
+ *
+ * Each one is a vision call with a 4 minute timeout that costs real money, and the
+ * work is detached from the request so nothing else bounds it. With one user this
+ * never mattered; with several it is the difference between a queue and a stampede.
+ */
+const MAX_CONCURRENT_SCANS = 2
+let inFlight = 0
+
+export function tryAcquireScanSlot(): boolean {
+  if (inFlight >= MAX_CONCURRENT_SCANS) return false
+  inFlight += 1
+  return true
+}
+
+export function releaseScanSlot(): void {
+  inFlight = Math.max(0, inFlight - 1)
+}
+
+export function scansInFlight(): number {
+  return inFlight
+}