chore(deps): take next 16, eslint-config-next 16 and the tailwind plugin

[isaacismaelx14]

Resolves Dependabot #1 through #7, verified together against the current tree.

Why not just merge them

Their CI results were not all trustworthy. #1, #2 and #3 are still based on a commit from before the monorepo was split into two apps and a UI package, so a green check there says nothing about the repo as it stands.

PR	Bump	Verdict
#6	next 15.5.23 to 16.3.1	taken
#7	eslint-config-next 15 to 16	taken, needed a config rewrite
#4	prettier-plugin-tailwindcss 0.6.14 to 0.8.1	taken, pure class-order churn
#1 #2 #3	checkout v7, setup-node v7, action-setup v6	taken, applied directly
#5	@types/node 22 to 26	rejected, see below
#8	eslint 9 to 10	blocked upstream, see below

The eslint pair was coupled

#8 failed with Failed to patch ESLint because the calling module was not recognized: eslint-config-next 15 patches ESLint internals that v10 moved.

#7 failed separately with Converting circular structure to JSON from @eslint/eslintrc, because our config wrapped the legacy config in FlatCompat.

eslint-config-next 16 exports flat config arrays from its subpaths, so the wrapper is gone:

import nextCoreWebVitals from "eslint-config-next/core-web-vitals";
import nextTypescript from "eslint-config-next/typescript";

@eslint/eslintrc is now unused and removed.

#8 is blocked upstream, not by us

With the config fixed, eslint 10 still fails, one layer deeper:

TypeError: Error while loading rule 'react/display-name':
contextOrFilename.getFilename is not a function
  at resolveBasedir (eslint-plugin-react/lib/util/version.js:31)

eslint-plugin-react@7.37.5, pulled in transitively by eslint-config-next, calls context.getFilename(), which ESLint 10 removed. Nothing on our side fixes that. Confirmed by testing: eslint 9 + eslint-config-next 16 lints clean. #8 should stay open until eslint-plugin-react ships ESLint 10 support.

#5 rejected on purpose

CI and Railway both run Node 20.20.2, and engines says >=20.11.0. @types/node@26 is six majors ahead of the runtime: it would let tsc accept APIs that do not exist in production. Types belong near the runtime.

The real fix is a separate decision: pin the types to the runtime major, or move the runtime to a newer LTS. Worth doing, but not inside a dependency bump.

A bug of ours that next 16 found

The documentation loader located its content directory by walking up looking for a marker. The bundler cannot analyse that, so it concluded any file in the project might be read:

Static analysis determined that this filesystem access causes the whole project to be traced and included in the output.

That would have shipped the entire source tree as server code. A statically scoped path traces content/ and nothing else. The build now emits zero warnings.

Verification

format:check, lint, typecheck, test (88) and build all pass locally on both apps and both packages, from a clean .next.

Note: next build while a next dev server is running on the same app clobbers its .next and produces module-not-found errors that look like a real failure. That is what the first build attempt here was.