i18n: middleware rewrite instead of /[locale] routes

The site serves Chinese and English. The obvious implementation is /[locale]/... routes. We chose a middleware rewrite instead, and it has a real cost worth writing down.

How it works: URLs stay clean (/tools, not /zh/tools). Middleware inspects a cookie and Accept-Language, rewrites to a locale-prefixed internal path, and sets an x-locale header. Server components read that header and pick a dictionary.

Why not subpaths: for a bilingual site where most users want one language, subpaths mean every internal link has to carry a locale segment, and the "default" URL becomes ambiguous.

The cost, stated plainly: route handlers and server components cannot be statically pre-rendered, because the response depends on a request header. That is why tool pages render dynamically. If we moved to subpaths, static generation and per-locale caching would open up.

It is a reasonable trade for the current shape of the site, not a permanent decision.