Next.js managed-functions deploy fails at activation — "Failed to deploy the Azure Functions" (~15s poll, no diagnostic)

### Describe the bug

A GitHub Actions deploy of a **Next.js (App Router) managed-functions** app to Azure Static Web Apps consistently fails at the **managed-functions activation step**. The Oryx build and artifact upload both succeed; Azure's post-upload deployment poll then fails after ~15s with:

```
Status: Failed. Time: 15.3s
Deployment Failed :(
Deployment Failure Reason: Failed to deploy the Azure Functions.
```

There is **no further diagnostic** in the GitHub Actions log, and the portal's SWA deployment detector only lists the failed deployments (Managed Function Language = node 22) and refers back to the GitHub Actions logs. We cannot locate the underlying activation error anywhere we have access to.

### Environment

- **Action:** `Azure/static-web-apps-deploy@v1`, `action: upload`, `app_location: /`, `output_location: ""`, `app_build_command: npm run build`
- **Framework:** Next.js 16 (App Router), hybrid (static + server/SSR + 6 `/api/*` managed functions)
- **Runtime:** Oryx detects Node 22.x; Managed Function Language node 22
- **Build step log (succeeds):** `Repackaged Next.js app to deploy on the backend.` → `Finished building function app with Oryx` → `Finished Upload. Polling on deployment.`

### Symptom timeline (UTC, all `push`-triggered to the same SWA)

| Time | Commit | Result |
|------|--------|--------|
| 14:55 | A | success |
| 16:25 | B | **fail** |
| 16:59 | C | **fail** |
| 17:27 | D | **fail** |
| 17:41 | A (re-run of the 14:55 commit) | success |
| 17:48–17:53 | D, 3 retry attempts | **fail ×3** |

- Identical failure signature every time: upload OK → `Status: Failed` after ~15–22s → "Failed to deploy the Azure Functions."
- **Successful** deploys poll for ~90s before `Status: Succeeded`; **failures** fast-reject at ~15s.
- We wrapped the deploy step in 3 retries; all three attempts of the same commit failed identically — so it is **not** a transient single-call timeout.

### What we ruled out (comparing the last-passing commit A vs the first-failing commit B)

- **No dependency change** — `package.json` / `package-lock.json` identical.
- **No config change** — `next.config.ts`, `staticwebapp.config.json` identical.
- **No new routes / functions** — identical route manifest: 29 routes, same 6 `/api/*` managed functions.
- **No meaningful bundle difference** — built both commits locally; both produce `.next/server` = 27 MB, 216 files; total server bytes differ by **~8 KB (~0.2%)**, entirely from a few small source edits.
- App builds cleanly (`next build` exit 0) and runs correctly in local dev. The failure is **only** at managed-functions **activation**, after a successful upload.

### SWA CLI does not reproduce (different deploy path)

Tried `swa deploy` (CLI 2.0.9) with `--verbose=silly` as a local repro. The CLI takes a **different path** than the GitHub Action — it `Skipping step to build .next with Oryx`, treats the output as static content, and looks for an `index.html`, rather than running the managed-Next.js Oryx repackaging the Action uses. It also defaults `FUNCTION_LANGUAGE_VERSION: 16` vs node 22 in the Action. So the CLI cannot exercise the failing Oryx managed-functions flow.

### Expected behavior

Either the deploy succeeds (as it does intermittently / on other commits), or the "Failed to deploy the Azure Functions" error surfaces an **actionable reason** (which function, what limit, what validation) somewhere accessible to the developer.

### Questions

1. Where can we see the **actual activation error** behind "Failed to deploy the Azure Functions"? It is absent from the Actions log and the portal detector.
2. Is there a **size / count / shape limit** on the packaged managed-functions payload that a Next.js App Router app can intermittently exceed, and how can we inspect the rejected payload?
3. Was there a **platform-side change/incident** to managed-functions activation around 2026-06-01 16:00 UTC? A commit that deployed fine earlier now also fails on re-run, which points away from our code.

Happy to provide the full raw deploy log and the resource details privately.