CI: aem-psi-check is meaningless for next/ Next.js subproject changes

[lamontacrook]

Problem

PR #2 introduces a Next.js + RSC rendering layer under next/ (see #1). The repo's aem-psi-check (EDS PageSpeed Insights bot) fails on it, but the failure is not about the spike's code:

• The bot runs Lighthouse against the EDS feature preview ({branch}--next-eds--AdobeDevXSC.aem.page) — the standard vanilla-EDS site. The Next.js app is not deployed there; it's a next/ subproject that builds and runs separately (Cloudflare Worker via OpenNext).
• So the check measures a surface unrelated to the change, and currently can't resolve a meaningful score (branch has no published .live content; nothing under next/ affects the EDS preview).

Net: changes scoped to next/** will always show a red check that says nothing about the React rendering path we actually care about.

Options

1. Scope the EDS PSI workflow to ignore next/** — skip aem-psi-check when a PR only touches the Next subproject (paths-ignore / path filter in .github/workflows). Cleanest short-term fix.
2. Add a dedicated Lighthouse job for the Next app — run PSI/Lighthouse against a deployed Cloudflare preview of the Next app (deploy:cf:preview). This is the number that actually matters for the headless-RSC architecture and lets us hold the ~100 target on the real rendering path.
3. Both — (1) to unblock, (2) to get a real performance signal.

Recommendation

Do (1) now to stop the false-negative, then (2) as the Next app matures (needs a Cloudflare account/zone + deploy creds in CI).

Context

• Architecture/spike: Spike: render EDS content via Next.js RSC, starting with Hero block #1
• PR: Spike: render EDS content via Next.js RSC + Cloudflare deploy target #2
• The check: aem-psi-check, fails on next/-only changes.