docs: call the redirect step a redirect, not a rewrite

The lifecycle step added last commit was headed "Declarative rewrites",
and neither key rewrites anything: webjs.redirects replies with a
configured redirect status and a Location header, and webjs.trailingSlash
308-redirects the non-canonical form. A rewrite is a distinct concept the
audience for this page brings from Next, where it proxies internally with
no client-visible redirect, and WebJs ships no such key, so the heading
invented a feature. Every other surface this PR touches already says
redirect.

Author: vivek7405

website/app/docs/architecture/page.ts

@@ -104,7 +104,7 @@ import { listPosts } from '#modules/posts/queries/list-posts.server.ts';</code-b
     <ol>
       <li><strong>HTTP request arrives</strong> at the listener shell (<code>node:http</code>, or <code>Bun.serve</code> on Bun; HTTP/2 if TLS is configured).</li>
       <li><strong>The listener shell answers what does not fit the request/response model</strong>, before the app handler is called at all: a <strong>WebSocket upgrade</strong> bound for a <code>route.ts</code> that exports <code>WS</code>, and in dev the live-reload <strong>SSE stream</strong> at <code>/__webjs/events</code>. Both are intercepted on the node and Bun shells alike. The node shell also emits <strong>103 Early Hints</strong> here in production, with modulepreload URLs for the matched page; Bun has no informational-response API, so that step does not exist on the Bun shell.</li>
-      <li><strong>Declarative rewrites from your <code>webjs</code> config are applied</strong>: <code>webjs.redirects</code> and <code>webjs.trailingSlash</code>. These are configured by your app but resolved by the framework ahead of everything below, so a 308 from a redirect rule is answered without your root middleware running. That is the case most likely to surprise you, so it is worth remembering specifically.</li>
+      <li><strong>Declarative redirects from your <code>webjs</code> config are answered</strong>: <code>webjs.redirects</code> and the <code>webjs.trailingSlash</code> canonical-form policy, both of which reply with a redirect status and a <code>Location</code> header rather than routing the request onward. These are configured by your app but resolved by the framework ahead of everything below, so a 308 from a redirect rule is answered without your root middleware running. That is the case most likely to surprise you, so it is worth remembering specifically.</li>
       <li><strong>Framework-internal assets and probes are answered next</strong>, because they depend on neither the app analysis nor the vendor importmap and a cold instance must not gate them: the health, readiness and build-info probes (<code>/__webjs/health</code>, <code>/__webjs/ready</code>, <code>/__webjs/version</code>), the core runtime (<code>/__webjs/core/*</code>), the dev reload client and its SharedWorker (<code>/__webjs/reload.js</code>, <code>/__webjs/reload-worker.js</code>), and downloaded vendor bundles (<code>/__webjs/vendor/*</code>). Not everything under <code>/__webjs/*</code> is here: the server-action RPC endpoint is routed with the app, below. In <strong>development only</strong>, <code>/public/*</code> plus the <code>/sw.js</code> and <code>/offline.html</code> root remaps and <code>/favicon.ico</code> are served here too, so a stylesheet is never queued behind the startup analysis.</li>
       <li><strong>Root middleware</strong> (<code>middleware.ts</code>) runs next if present, for every request not already answered above. The rule behind the exceptions is worth holding onto rather than the list: anything the listener shell or the framework's pre-analysis stage answers never reaches your middleware, and everything routed with the app does.</li>
       <li><strong>Route matching</strong>: the router tries (in order) the server-action RPC endpoint (<code>/__webjs/action/&lt;hash&gt;/&lt;fn&gt;</code>), static files, user source modules, API routes (<code>route.ts</code>), then page routes. The action endpoint is routed here rather than answered early, so root middleware DOES run for a server action, which is what lets you gate actions with auth or rate limiting. In production this is also where <code>/public/*</code> is served, so a middleware that guards an asset still guards it.</li>