withPayload: scope the client-hint header injection to the admin route instead of '/:path*'

withPayload adds Accept-CH / Vary / Critical-CH: Sec-CH-Prefers-Color-Scheme on source: '/:path*' — every route of the host app (observed in @payloadcms/next@3.88.0, dist/withPayload/withPayload.js). The injection exists so the admin panel can server-render the correct theme without a flash (getRequestTheme reads the hint), which is right — but Critical-CH on public routes makes every cold Chromium navigation discard the response and retry it (an internal 307 to the same URL). For sites that pin a colour scheme and never read the preference, that is a wasted document round trip on every visitor's first page view, and it silently corrupts headless-browser TTFB measurement (the retried response is served from local cache, so the final hop reads ~0 ms).

Since withPayload doesn't currently know the admin route, could the entry be scoped via an option — e.g. accept the admin base path, or a clientHintHeaders: 'admin-only' | 'all' | false — defaulting to today's behaviour for compatibility?

Workaround we ship today: post-process the returned config, moving the injected entry from '/:path*' to '/:path(admin|admin/.*)':

const payloadConfig = withPayload(nextConfig, options)

export default {
  ...payloadConfig,
  headers: async () => scopeClientHintHeadersToAdmin((await payloadConfig.headers?.()) ?? []),
}

Happy to PR the option if the approach is agreeable.

Start in dist/withPayload/withPayload.js, tracing how withPayload creates the headers entry for '/:path*' and how the admin route is represented. Done means the client-hint injection can be scoped to the admin route without breaking the existing compatibility behavior; the issue does not name a test file.