Templates pin Next.js 14, which has no patch for three HIGH advisories — the fix line starts at 15.5.21

Filed per the 2026-08-12 standup.

## The problem

`templates/base/apps/web/package.json.hbs` pins `next: ^14.0.0`, which resolves to **14.2.35**. Three HIGH-severity advisories cover that version and **none of them has a 14.x patch**:

| advisory | severity | vulnerable | first patched |
|---|---|---|---|
| [GHSA-89xv-2m56-2m9x](https://github.com/advisories/GHSA-89xv-2m56-2m9x) — SSRF in Server Actions on custom servers | HIGH | `>= 14.1.1, < 15.5.21` | **15.5.21** |
| [GHSA-p9j2-gv94-2wf4](https://github.com/advisories/GHSA-p9j2-gv94-2wf4) — SSRF in rewrites via attacker-controlled destination hostname | HIGH | `>= 12.0.0, < 15.5.21` | **15.5.21** |
| [GHSA-m99w-x7hq-7vfj](https://github.com/advisories/GHSA-m99w-x7hq-7vfj) — DoS in App Router using Server Actions | HIGH | `>= 13.0.0, < 15.5.21` | **15.5.21** |

Every fix landed on the 15.5.x line, so there is no patch release to move to inside 14. Staying on 14 means staying exposed, which makes this a version bump rather than a dependency update.

`pnpm audit` on a freshly generated `-t farcaster-miniapp` scaffold reports **41 advisories, 21 of them against `next`** — 8 high, 11 moderate, 2 low. Every `patched_versions` range on those 21 begins at 15.x.

## What the upgrade actually involves

Not as much as it sounds. Tested against a `minipay` scaffold with `next` bumped to `^16.3.0`, `eslint-config-next` to `^16.3.0` and `typescript` to `^5.9.3`:

- **React stays on 18.** Next 16 peers `react: ^18.2.0 || ^19.0.0`, so no React major is forced.
- **`pnpm type-check` passes.**
- **The templates use none of the Next 15 breaking surface.** `grep` for `cookies()`, `headers()`, `params`, `searchParams` and `draftMode()` across `templates/base`, `minipay`, `farcaster-miniapp` and `wallets/` returns nothing — the async request APIs are the main 14→15 break and no template touches them.

**One real decision, and it is the whole migration:** Next 16 defaults to **Turbopack**, and `templates/base/apps/web/next.config.js.hbs` carries a `webpack:` block. Next says so itself and stops:

```
⨯ ERROR: This build is using Turbopack, with a `webpack` config and no `turbopack` config.
As of Next.js 16 Turbopack is enabled by default and custom webpack
configurations may need to be migrated to Turbopack.
```

With `--webpack` the same build compiles and generates static pages. So the choice is: port that config to Turbopack, or pin the build to webpack and say why.

That `webpack:` block is not incidental — it holds the `resolve.alias → false` stub for the unresolved `@x402` optional peers (#398, fixed in #434). Whatever replaces it has to keep that working, and the ai-chat template now carries an equivalent block for the same reason.

**Alternative worth considering:** `15.5.23` clears all three HIGH advisories and is the last 15.x, which sidesteps the Turbopack question entirely. Smaller change, same security outcome, at the cost of being a major behind.

## Scope

- `templates/base/apps/web/package.json.hbs` — `next`, `eslint-config-next`, `typescript`
- `templates/base/apps/web/next.config.js.hbs` — the bundler decision
- `templates/ai/chat-template/` — already on `next 15.3.6`, still below 15.5.21, so it needs the same bump and has its own `next.config.ts`

Deliberately **not** claiming a supply-chain compromise. The August npm worm hit `keyv`, `cacheable`, `flat-cache` and `file-entry-cache`; those do reach the tree through `eslint`, but at pre-attack versions (`keyv@4.5.4`, `flat-cache@3.2.0`, `file-entry-cache@6.0.1`) and none appears in `pnpm audit`. This issue is only about the Next.js advisories.

Reproduced against `main` @ `f0750b5`.