console: bump to next 16.4 when stable; re-evaluate outputFileTracingIncludes vs Dockerfile CBOR staging (upstream symlink-tracing panic fixed in canary)

## Context

`apps/console/next.config.mjs` deleted `outputFileTracingIncludes` because Turbopack's NFT emitter panics (`TurbopackInternalError: … Is a directory (os error 21)`) when a tracing glob matches a symlink-to-directory — pnpm's `.pnpm` layout guarantees such matches. The CBOR codec is shipped via Dockerfile staging instead (`scripts/stage-cratestack-cbor-for-docker.mjs` + literal-dir COPY + `scripts/link-standalone-cratestack.mjs`). Full mechanism documented in the config file's own comment block.

## Upstream status (verified 2026-08-31, minimal 4-file repro)

- next **16.3.2** and **16.3.3** (latest stable): panic reproduces. Trigger isolated: symlink-to-dir + matching glob; removing either one → green build.
- next **16.4.0-canary.12**: fixed — build succeeds AND the standalone output traces both the symlink and its target correctly.
- Fix: https://github.com/vercel/next.js/pull/97507 (merged 2026-08-18). Nothing to file upstream — a new report would be a duplicate of an already-merged fix.

## Task, when next ≥16.4 stable ships

1. Bump `next` in `apps/console`.
2. Re-verify the panic is gone with the real workspace globs (not just the minimal repro).
3. Decide: restore `outputFileTracingIncludes` for `@cratestack/*` and retire the three-part Dockerfile staging workaround (staging script, literal COPY, in-image linker), OR keep the Dockerfile path if it's judged more explicit. Either way, update the config comment block — it currently documents the panic as unfixable.

## Verification evidence

Repro + logs preserved locally (session scratchpad `turbopack-repro/`): `turbo-build.log` (panic on 16.3.2), `v1633-build.log` (panic on 16.3.3), `control-a.log`/`control-b.log` (green without symlink / without glob), `canary-build.log` (green on 16.4.0-canary.12).

Source of truth: https://github.com/vercel/next.js/pull/97507