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/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');