GeezerVison

Picks up the Next 16.2.12 revert (#6242). The earlier merge had taken
staging's 16.3.0; this takes the revert in apps/docs, apps/sim and
packages/emcn and regenerates the lockfile. lucide-react stays removed.

…live code (#6777)

* chore(deps): upgrade next to 16.3.1, its optimizer no longer deletes live code

16.3.0 was reverted in #6242 because its Turbopack optimizer modelled a bare
`return <asyncCall>()` tail call inside an async function as returning the
promise object, propagated that always-truthy fact through the caller's `await`,
and deleted everything after the resulting `if`. That shipped two dead code
paths to production: the whole `POST /api/credentials` create path, and the
insert inside `upsertAsyncToolCall`.

We reported it as vercel/next.js#96595. The fix — "[turbopack] Collapse nested
promises in the analyzer" (vercel/next.js#96601) — folds `Promise<Promise<T>>`
to `Promise<T>` in the analyzer, and was backported as #96675 and released in
16.3.1.

Verified before taking the bump:

- The minimal reproduction from the issue no longer reproduces on 16.3.1. All
  four routes keep their code; on 16.3.0 `/api/broken` lost everything after
  the `if`.
- A production build of `apps/sim` on 16.3.1 still emits the markers whose
  disappearance was the original signal: `credential_connected` (43 files),
  `acquireOrganizationUserMutationLocks` (28), and the `upsertAsyncToolCall`
  insert-path warning (10).

The `return await` hardening added to both sites in the revert stays as is, and
so does the TypeScript toolchain configuration.

16.3.1 published 2026-08-13, so it is inside the 7-day `minimumReleaseAge`
supply-chain window until 2026-08-20 and needs an exclusion to install. The
alternative is sitting on 16.2.12, whose successor we already reverted once, so
the entries go in dated and come out on the next touch of the file. The mermaid
and js-yaml exclusions aged out on 2026-08-11 and 2026-08-07 and are dropped
here per that same rule.

* fix(deps): keep the musl and win32 SWC binaries in the lockfile

The release-age exclusion only listed the four @next/swc platforms that
package.json pins, but next declares all eight as its own optionalDependencies,
so all eight are normally resolved into bun.lock. A gated optional dependency
does not fail the install — bun drops it silently — so the first install
stripped both musl variants and both win32 variants from the lockfile.

That left the Alpine devcontainer and any Windows machine with no SWC binary to
resolve. Adding the remaining four to the exclusion list restores all eight
entries at 16.3.1.

Worth knowing for the next time this happens: bun.lock is sticky here. Once an
optional dependency has been dropped, re-running the install — even with
--force, even with the age gate switched off entirely — does not bring it back,
because the resolution is not reattempted. The lockfile has to be regenerated
from a base that still contains the entries, which is why this restores
bun.lock from staging before re-applying the bump.