web: the QR card hands out the look that made the photo

A photo's landing section can now be the QR card, and that section is the
only one that hands something out: the server writes the photo's own stored
look back as the app's .recipe file, at
GET /api/photos/:id/preset.recipe, for any row the curator ticked into the
qr slot. Nothing new is stored — the file is built from the recipe the
upload already carried, so it works for a photo uploaded by the phone too.

The admin pane grows a fourth checkbox and a fourth row (QR card); the
row draws the download link as a scannable code, and the box is dead for a
photo with no stored look. The landing's QR card now encodes the curated
photo's own link instead of a mock address. The listing exposes
hasPreset, never the recipe itself.

docker/frontend/src/i18n/en.ts

@@ -168,8 +168,10 @@ export const en: Dict = {
   'adm.pickStrip': 'Film strip',
   'adm.pickTester': 'Live preset tester',
   'adm.pickCreator': 'Custom recipe creator',
+  'adm.pickQr': 'QR card',
+  'adm.noPreset': 'no look to hand out',
   'adm.rowEmpty': 'Nothing here yet.',
-  'adm.slotHint': 'Tick the sections a photo should appear in — a photo can sit in several at once, and each section draws one of its own at random per visit. Unticking every box takes the photo off the landing page without deleting it — its owner keeps it in MY PHOTOS.',
+  'adm.slotHint': 'Tick the sections a photo should appear in — a photo can sit in several at once, and each section draws one of its own at random per visit. Unticking every box takes the photo off the landing page without deleting it — its owner keeps it in MY PHOTOS. The QR section is the one that hands the look out: its card shows a code that downloads the photo’s own .recipe file for the phone app to scan in.',
   'adm.signIn': 'Sign in with an admin account',
   'adm.notAdmin': 'This account has no admin rights.',
   'adm.empty': 'No contributions yet.',