docs: finish propagating the csp correction to the last two surfaces

The previous commit fixed the "array, string, and object shapes" claim in
the d.ts and left it standing in built-ins.md and the docs page, so one
commit shipped two answers for why csp escapes the boolean check. It has no
schema type at all, being a oneOf, so no shape list can be right; all four
surfaces now name the eight keys and say nothing about their types.

Two leftover framings go with it. built-ins.md gave a false cause for the
boot check ignoring doctor.gate (who reads the key, rather than the real
reason, which is that the check never descends into any key). The docs page
still called doctor "the one part of the block that is never merely
dropped", written before this check existed and untrue now that a bad enum
or boolean warns and is dropped too.

Author: vivek7405

.agents/skills/webjs/references/built-ins.md

@@ -145,7 +145,7 @@ setFileStore(diskStore({ dir: '/var/data/uploads', baseUrl: '/files' }));
 
 ## The `"webjs"` config block (package.json)
 
-All keys are optional, and a malformed entry in a key the SERVER reads is dropped at boot rather than crashing the pipeline, some readers warning as they drop it. An UNKNOWN top-level key no longer passes in silence either (#1300): the block is validated against the published JSON Schema once per boot, in dev and in prod alike, and one aggregated warning names what was ignored. So a `"redirect"` typed for `"redirects"` now says so in the server output instead of silently leaving the feature at its default. It never fails the boot. Know its exact reach, since what it passes over looks like what it catches. It reports an unknown TOP-LEVEL key, a bad `enum` value, and a wrong-typed `boolean` / `integer`, which is 9 of the 17 keys. It does not descend into a nested object, so a misspelling inside `dev` or `start` is not reported, and it does not type-check the other 8 (`headers`, `redirects`, `basePath`, `allowedOrigins`, `csp`, `dev`, `start`, `doctor`), which are the free-form array, string, and object shapes where a blunt check would start refusing configs that work. Whether anything else notices a value this check passes over is up to that value's own reader, and it varies by reader. `doctor.gate` is the one that varies furthest: it is read by the `webjs doctor` CLI rather than the server at all, so the boot check never looks inside it, and the CLI rejects a bad entry outright (see the doctor severity gate below): a gate whose typo was quietly ignored would leave CI un-gated while looking gated, which is the one thing that mechanism cannot afford.
+All keys are optional, and a malformed entry in a key the SERVER reads is dropped at boot rather than crashing the pipeline, some readers warning as they drop it. An UNKNOWN top-level key no longer passes in silence either (#1300): the block is validated against the published JSON Schema once per boot, in dev and in prod alike, and one aggregated warning names what was ignored. So a `"redirect"` typed for `"redirects"` now says so in the server output instead of silently leaving the feature at its default. It never fails the boot. Know its exact reach, since what it passes over looks like what it catches. It reports an unknown TOP-LEVEL key, a bad `enum` value, and a wrong-typed `boolean` / `integer`, which is 9 of the 17 keys. It does not descend into a nested object, so a misspelling inside `dev` or `start` is not reported, and it does not type-check the other 8 (`headers`, `redirects`, `basePath`, `allowedOrigins`, `csp`, `dev`, `start`, `doctor`), whose schemas are the free-form ones a blunt check would start refusing working configs over. Whether anything else notices a value this check passes over is up to that value's own reader, and it varies by reader. `doctor.gate` varies furthest, since the boot check never descends into any key and the `webjs doctor` CLI, not the server, is what reads this one, rejecting a bad entry outright (see the doctor severity gate below): a gate whose typo was quietly ignored would leave CI un-gated while looking gated, which is the one thing that mechanism cannot afford.
 
 ### Security headers
 

website/app/docs/configuration/page.ts

@@ -162,8 +162,8 @@ webjs routes --help     # one command's help (flag form)</code-block>
     <h2>Config typos are reported at boot</h2>
     <p>Every key in the <code>webjs</code> block is optional, which means an unknown one has no way to announce itself: write <code>"redirect"</code> for <code>"redirects"</code> and the key is simply never read, the feature sits at its default, and the app looks configured. So WebJs validates the block against its published JSON Schema once per boot, in development and in production alike, and prints a single warning naming what it ignored.</p>
     <p>It is a <strong>warning, never a failure</strong>. A typo costs one feature its setting, and refusing to boot over that would cost the whole app, usually mid-deploy.</p>
-    <p><strong>What it catches, and what it does not.</strong> It reports an unknown top-level key, a value outside an allowed set (<code>trailingSlash</code>), and a wrong-typed boolean or whole number (<code>elide</code>, <code>seed</code>, <code>clientRouter</code>, <code>maxBodyBytes</code>, <code>maxMultipartBytes</code>, and the three timeouts). That is 9 of the 17 keys. It does not descend into nested objects, so a key misspelled inside <code>webjs.dev</code> or <code>webjs.start</code> is missed, and it does not check the type of the other 8 (<code>headers</code>, <code>redirects</code>, <code>basePath</code>, <code>allowedOrigins</code>, <code>csp</code>, <code>dev</code>, <code>start</code>, <code>doctor</code>), which are the free-form array, string, and object shapes where a blunt check would start rejecting configs that work. Give one of those the wrong type outright, as in <code>"headers": "x"</code>, and it passes this check. Whether anything downstream then says so is up to that key's own reader.</p>
-    <p>Editors catch more of this earlier still: a scaffolded app wires the schema into <code>.vscode/settings.json</code>, and the <code>WebjsConfig</code> type from <code>@webjsdev/core</code> types the block while you author it. The one part of the block that is never merely dropped is <code>webjs.doctor</code>, which the server does not read at all and which <code>webjs doctor</code> exits non-zero on when it is malformed, because a silently ignored gate would leave CI un-gated while looking gated.</p>
+    <p><strong>What it catches, and what it does not.</strong> It reports an unknown top-level key, a value outside an allowed set (<code>trailingSlash</code>), and a wrong-typed boolean or whole number (<code>elide</code>, <code>seed</code>, <code>clientRouter</code>, <code>maxBodyBytes</code>, <code>maxMultipartBytes</code>, and the three timeouts). That is 9 of the 17 keys. It does not descend into nested objects, so a key misspelled inside <code>webjs.dev</code> or <code>webjs.start</code> is missed, and it does not check the type of the other 8 (<code>headers</code>, <code>redirects</code>, <code>basePath</code>, <code>allowedOrigins</code>, <code>csp</code>, <code>dev</code>, <code>start</code>, <code>doctor</code>), whose schemas are the free-form ones a blunt check would start rejecting working configs over. Give one of those the wrong type outright, as in <code>"headers": "x"</code>, and it passes this check. Whether anything downstream then says so is up to that key's own reader.</p>
+    <p>Editors catch more of this earlier still: a scaffolded app wires the schema into <code>.vscode/settings.json</code>, and the <code>WebjsConfig</code> type from <code>@webjsdev/core</code> types the block while you author it. And <code>webjs.doctor</code> is checked by a different tool entirely: the server never reads it, and <code>webjs doctor</code> exits non-zero on a malformed one, because a silently ignored gate would leave CI un-gated while looking gated.</p>
 
     <h2>Environment Variables</h2>
     <p>Use <code>process.env</code> in server-side code (pages, actions, route handlers, middleware). WebJs auto-loads <code>&lt;appDir&gt;/.env</code> into <code>process.env</code> once at boot using Node 24+'s built-in <code>process.loadEnvFile</code>, so a scaffolded app with a committed <code>.env.example</code> and a developer-copied <code>.env</code> just works without installing <code>dotenv</code> or wiring up the file path. The auto-load fires before any server-only module is imported, which matters for code that reads <code>process.env</code> at module-init time (e.g. <code>createAuth({ secret: process.env.AUTH_SECRET })</code>).</p>