Swap local AI fallback model from 3B to 1B for mobile speed

Real report: the 3B local model (WebLLM, in-browser) made things
noticeably slow, especially on mobile where WebGPU memory budgets are
often under 1-1.5GB. Llama-3.2-1B-Instruct is the same Meta family/
generation as the 3B model was, specifically built by Meta for on-
device/edge use, at roughly 1/2.6 the VRAM (879MB vs. 2,264MB,
verified directly against WebLLM's own prebuilt config) — a real but
smaller capability gap than the original 360M model had.

index.html

@@ -345,7 +345,7 @@
     <div class="cap-banner-active" id="capBannerActive" style="display:none;align-items:center;justify-content:space-between;gap:10px;">
       <div class="cap-title">🖥️ Local AI mode — <span class="info-term" id="localLimitedTerm" tabindex="0" role="button" aria-expanded="false" aria-describedby="localLimitedTooltip">limited<div class="tooltip-bubble" id="localLimitedTooltip" role="tooltip">
         <ol>
-          <li><strong>Smaller model</strong> — it's a 3B-parameter model, on par with Nox's own server-side "Standard" tier but below the 8B "Smart" tier. A real, if smaller, capability gap versus the server's best — and a much bigger download than a phone-class model, so it can take a while on a slow connection.</li>
+          <li><strong>Smaller model</strong> — it's a 1B-parameter model, chosen specifically to run smoothly on phones and slower devices (WebGPU memory is often tight on mobile). A real capability gap versus the server's best ("Smart", 8B), but a much smaller, faster download than a bigger model would be.</li>
           <li><strong>No images</strong> — it's text-only. Attaching a photo/document in local mode gets declined with a message telling you to switch back to the server.</li>
           <li><strong>No live data</strong> — the server injects real-time weather, news, currency rates, holidays, and general web facts into its answers. Local mode has none of that — it's just the raw model guessing from its own training, so it'll be wrong or evasive on anything time-sensitive ("what's the weather," "who won yesterday," etc.).</li>
           <li><strong>No date awareness</strong> — the server also tells the model today's actual date; local mode doesn't get that either, so it may not know what day it is.</li>
@@ -1772,18 +1772,25 @@ function tickCapCountdown() {
 // message cap) is exhausted, a visitor can opt into running a small model
 // entirely in their own browser via WebGPU (@mlc-ai/web-llm) instead of
 // waiting it out. This is a real capability downgrade versus the server's
-// best ("Smart", 8B) — though upgraded from the original 360M-parameter
-// choice to the same 3B-class Llama model as the server's "Standard" tier,
-// trading a much bigger one-time download for noticeably better coherence
-// and reasoning — so it's opt-in, clearly labeled everywhere it's active,
-// and only ever offered when the browser actually supports it: WebGPU has
-// no CPU/WASM fallback in this library, so there's no point offering a
-// button that would just fail. esm.run's ES-module-only build is fine
-// here (unlike the earlier pdf.js mobile-webview issue) because any
-// browser new enough to have WebGPU support is already far newer than the
-// module-support gap that caused that bug.
+// best ("Smart", 8B). Went through two model choices before landing here:
+// the original 360M model was too weak (noticeably less coherent), then
+// a 3B model (same class as the server's "Standard" tier) fixed that but
+// real report — the 3B model made things noticeably slow, especially on
+// mobile, where WebGPU memory budgets are often under 1-1.5GB. Settled on
+// Llama-3.2-1B — same Meta family/generation the 3B was, and specifically
+// one of the models Meta built for on-device/edge use, at roughly 1/2.6
+// the VRAM (verified directly against WebLLM's own prebuilt config
+// before shipping: 879MB vs. 2,264MB) — real, if smaller, capability gap
+// versus 3B, but nowhere near as weak as the original 360M was. Opt-in,
+// clearly labeled everywhere it's active, and only ever offered when the
+// browser actually supports it: WebGPU has no CPU/WASM fallback in this
+// library, so there's no point offering a button that would just fail.
+// esm.run's ES-module-only build is fine here (unlike the earlier pdf.js
+// mobile-webview issue) because any browser new enough to have WebGPU
+// support is already far newer than the module-support gap that caused
+// that bug.
 const HAS_WEBGPU = typeof navigator !== 'undefined' && !!navigator.gpu;
-const LOCAL_MODEL_ID = 'Llama-3.2-3B-Instruct-q4f16_1-MLC';
+const LOCAL_MODEL_ID = 'Llama-3.2-1B-Instruct-q4f16_1-MLC';
 // Mirrors worker.js's own CRISIS_RE / CRISIS_RESPONSE exactly. Local mode
 // bypasses the server entirely, so without this a crisis message would go
 // straight to an unsupervised local model with zero safety net — this