revalidatePath()/revalidateTag() crash pages on Amplify Hosting (unsupported on-demand ISR) -- used after nearly every mutation

# What happened

The `tableName: null` crash originally reported against GH-393 (`Value null at 'tableName' failed to satisfy constraint: Member must not be null`) turned out to **not** be caused by the deploy race that issue fixed. After GH-393 shipped and was verified end-to-end (single serialized deploy, no `DeploymentInProgressError`), the exact same error recurred on a fully fresh, correctly-deployed build. Confirmed directly:

- The string `tableName` does not appear anywhere in our own compiled `.next/server/chunks/ssr/*.js` output (checked against a from-scratch local `npm run build` of the exact deployed commit).
- The error's stack trace cites chunk filenames that don't match our own build's chunk-naming convention at all -- this code isn't ours.
- It's intermittent per Lambda execution environment, including on cold-start requests, not deterministic.

# Update (2026-08-14): revalidatePath removal did NOT fix this -- real root cause found

The original theory below (on-demand ISR / `revalidatePath`/`revalidateTag` unsupported on Amplify's managed cache) was **necessary but not sufficient**. Both rounds of removal actually shipped:

- PR #396: removed all `revalidatePath()`/`revalidateTag()` calls app-wide, replaced with a `router.refresh()`-based hook (`useActionFormState`) for "stays in place" mutations.
- PR #397: removed 5 more leftover `revalidatePath()` calls in `web/lib/actions/cart.ts` that PR #396's page.tsx-focused sweep missed.

Despite both merged and deployed, the crash **still reproduces** -- confirmed by the user in a clean incognito window (ruling out stale client-side cookies/session), immediately after a fresh login, hitting `GET /dashboard`. CloudWatch (`/aws/amplify/d2t4r8ycfq1um5`) shows the identical `tableName: null` error, including on cold-start requests with zero `revalidatePath` calls left anywhere in the app's code, and intermittently across warm/cold requests on the *same* compute deployment ID. This rules out any remaining app-level on-demand-revalidation call as the trigger.

**Actual root cause (high confidence): this app runs Next.js 16.2.12, which Amplify Hosting's SSR compute does not yet officially support.**

- AWS's own docs: "Amplify Hosting compute fully manages server-side rendering (SSR) for apps built with Next.js versions 12 through 15."
- [`aws-amplify/amplify-js#14614`](https://github.com/aws-amplify/amplify-js/issues/14614): `@aws-amplify/adapter-nextjs`'s peer dependency explicitly restricts to `next < 16.0.0`.
- [`aws-amplify/amplify-hosting#4074`](https://github.com/aws-amplify/amplify-hosting/issues/4074): Next.js 16.1 build fails with `EEXIST` -- Turbopack creates symlinks in `.next/node_modules` that Amplify's bundler can't handle.
- [`aws-amplify/amplify-js#14600`](https://github.com/aws-amplify/amplify-js/issues/14600): open feature request asking for Next.js 16 support, not yet shipped.

Next 15 -> 16 changed the caching internals significantly (this app's own compiled `.next/required-server-files.json` shows `cacheComponents`, `cacheLife`, and a new cache handler config shape). Amplify Hosting's build pipeline auto-injects its own DynamoDB-backed cache handler into the compiled SSR output post-build; the working theory is that injection is wired for the pre-16 cache handler API shape, and calling into it against Next 16's actual (different) internal cache API surface is what's producing a null `tableName` at some call sites, non-deterministically depending on which code path executes -- explaining why it hits some requests on a given compute deployment and not others, including cold start with zero revalidate calls in play.

# What's wanted (revised)

**Downgrade `web/`'s Next.js dependency from 16.2.12 to the latest Next.js 15.x release** -- the officially AWS-supported ceiling. Specifically:

1. Audit `app/`, `lib/`, `components/` for any Next.js-16-only APIs actually in use (e.g. new `cacheComponents`/`cacheLife` primitives) before downgrading, since none should be needed given this app already forces full dynamic rendering and `cache: "no-store"` everywhere.
2. Downgrade `next` (and any tightly-coupled packages, e.g. `eslint-config-next`, `@aws-amplify/adapter-nextjs` if it pins a next range) to the latest 15.x.
3. Run full build + `tsc --noEmit` + Jest + Playwright e2e locally against the downgrade.
4. Deploy and verify against real `alpha` per this repo's Deploy verification policy: merge once CI is green, then confirm post-merge against the live Amplify Hosting build that the dashboard/login flow no longer throws the `tableName` error -- including repeated fresh-login and cart-mutation checks, since the failure mode is intermittent, not deterministic on a single request.

**Not in scope:** re-adding `revalidatePath`/`revalidateTag` anywhere -- the `router.refresh()` approach from PR #396 should stay regardless of the Next.js version, since Amplify's docs still call out on-demand ISR as unsupported even on officially-supported Next.js versions.

Keep the original sections below for history/context of the (correct, but incomplete) first-round diagnosis.

---

# Original report

## Root cause (high confidence) -- superseded, see Update above

This app's `amplify.yml`-driven Amplify Hosting app has `cacheConfig.type: AMPLIFY_MANAGED_NO_COOKIES` (Amplify's managed Next.js Data/Full-Route cache, backed by an AWS-internal DynamoDB table). AWS's own docs are explicit that this feature has a real limitation:

> **On-Demand Incremental Static Regeneration isn't working for my app.** ... Amplify doesn't currently support On-Demand ISR. If your app is using Next.js on-demand revalidation, this feature won't work when you deploy your app to Amplify.
> -- https://docs.aws.amazon.com/amplify/latest/userguide/troubleshooting-SSR.html#on-demand-isr-not-supported

`revalidatePath()`/`revalidateTag()` (Next.js's "on-demand revalidation" APIs) matched this exactly, and a matching community report (aws-amplify/amplify-hosting#3116) showed the same failure signature. This diagnosis was correct as far as it went (those calls were genuinely broken and worth removing, see PRs #396/#397) but was not the sole or even primary cause of the crash, per the Update section above.

## Testing

Per root `CLAUDE.md`'s testing policy, any behavior change needs a corresponding test. A Next.js major-version downgrade itself has no direct unit-test surface, but the existing Playwright e2e suite (`web/e2e/*.spec.ts`) already exercises borrow/return/reserve/edit/delete flows end-to-end against real deployed `alpha`, and should be run and confirmed passing (or at least not newly broken beyond the known chronic flake, see precedent in PR #392/#394/#396/#397) both locally and post-deploy as the actual verification that the downgrade fixes the live crash.