test(post): resolve USER_DIR via helpers; record why UG1/UG2/LD1 are red

lightbox-dims.spec.js hardcoded ../../../user, so a run against a checkout
detached from the served tree planted its fixture in a different user/ than
Grav renders and LD1 failed as an opaque "card never appeared" timeout.
Take USER_DIR from helpers instead, which honours GRAV_USER_DIR.

The three specs in this folder that fail do so for real, pre-existing
reasons, and both files' headers implied otherwise:

- UG1/UG2 specify a submit gate that is not implemented. post-form.js's
  only create-form guard is `converting > 0` (pre-FilePond HEIC
  conversion); it never inspects FilePond item state at submit time, and
  .photo-convert-status is created lazily by photoStatusEl() only from the
  HEIC paths — so for a plain JPEG the element never exists and both
  expectations fail as "element(s) not found". UG2 is the one that matters:
  a failed upload keeping its thumbnail is unguarded silent data loss.

- LD1's header described its root cause in the past tense, reading as
  fixed. entry-journal.html.twig:48-49 still emits {{ img.width }} /
  {{ img.height }}, so EXIF-rotated photos still declare pre-rotation dims
  and PhotoSwipe still squeezes them.

Left failing rather than skipped, per retries:0 — a red test here is a real
defect, and hiding these would lose both.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tests/ui/post/lightbox-dims.spec.js

@@ -3,11 +3,19 @@
 // browser actually renders for the linked image (BUG 2026-07-09: portrait
 // iPhone JPEGs squeezed to landscape in the fullscreen lightbox).
 //
-// Root cause: entry-journal.html.twig fed `img.width`/`img.height` (raw
+// Root cause: entry-journal.html.twig feeds `img.width`/`img.height` (raw
 // getimagesize() of the ORIGINAL file — EXIF orientation ignored) into
-// data-pswp-*, while the slide href pointed at that original, which browsers
+// data-pswp-*, while the slide href points at that original, which browsers
-// display EXIF-rotated. For a stored-landscape portrait photo the attrs said
+// display EXIF-rotated. For a stored-landscape portrait photo the attrs say
-// landscape while the pixels rendered portrait → PhotoSwipe squeezed them.
+// landscape while the pixels render portrait → PhotoSwipe squeezes them.
+//
+// ⚠️ THIS SPEC CURRENTLY FAILS — the root cause above is still live.
+// entry-journal.html.twig:48-49 remains `{{ img.width }}` / `{{ img.height }}`,
+// so the fixture (stored 800x600, EXIF Orientation=6) reports 800 while the
+// browser renders 600. Fixing it means sourcing the dimensions from a medium
+// Grav has already oriented rather than the raw original — which cannot be
+// verified locally, since the dev container has no php-exif and so never
+// applies auto_fix_orientation. Left failing so the squeeze stays visible.
 //
 // The invariant tested here is environment-proof: whatever file the slide
 // links to, its browser-rendered natural size must equal the data-pswp-*
@@ -24,10 +32,14 @@ const { test, expect } = require('@playwright/test');
 const path = require('path');
 const fs = require('fs');
 const { execSync } = require('child_process');
+// USER_DIR comes from helpers so GRAV_USER_DIR is honoured — without it a run
+// against a checkout detached from the served tree plants the fixture in a
+// different user/ than Grav renders, and LD1 fails as an opaque "card never
+// appeared" timeout.
+const { USER_DIR } = require('../helpers');
 
 // Stored 800x600 with EXIF Orientation=6: browsers render it 600x800 portrait.
 const EXIF_PORTRAIT = path.join(__dirname, '../../fixtures/test-photo-exif-portrait.jpg');
-const USER_DIR = path.join(__dirname, '../../../user');
 const DEMO_DAILIES = path.join(USER_DIR, 'pages/01.trips/italy-2026-demo/01.dailies');
 const DEMO_TRIP_URL = '/trips/italy-2026-demo';
 

tests/ui/post/upload-gate.spec.js

@@ -12,6 +12,20 @@
 //    silent-data-loss path.
 // post-form.js owns the complete gate (theme code; the form plugin is
 // GPM-managed and not patchable in-repo).
+//
+// ⚠️ BOTH CASES CURRENTLY FAIL — the gate they specify is NOT implemented.
+// post-form.js's only create-form submit guard is `converting > 0` (the
+// pre-FilePond HEIC conversion, "Hang on — a photo is still converting."). It
+// never inspects FilePond's item state at submit time. `.photo-convert-status`
+// is created lazily by photoStatusEl(), which only runs from setStatus() on the
+// HEIC paths — so for a plain JPEG the element never exists and both
+// expectations below fail as "element(s) not found", not as a wrong message.
+// refreshCollapse() does read data-filepond-item-state, but only to word the
+// <summary> ("Uploading N photos…"); it gates nothing.
+// These are therefore red specs describing intended behaviour. UG2 is the one
+// that matters: a failed upload keeping its thumbnail is a silent-data-loss
+// path with no guard. Left failing rather than skipped so the gap stays visible
+// — see the plan's open items.
 const { test, expect } = require('@playwright/test');
 const { fillEditor, findEntry, cleanupEntry, TEST_PHOTO } = require('../helpers');