Assistant: document why the connect intercept is load-bearing

Investigated whether CopilotKit offers an official thread flush instead
of the BFF connect intercept. It does have one (POST /threads/clear ->
runner.clearThreads()), but only on the fetch-router entrypoint — the
single-route adapter we mount (copilotRuntimeNextJSAppRouterEndpoint)
accepts exactly agent/run|connect|stop, info, transcribe at 1.62, so
threads/* is unreachable from our deployment (verified: 400 Unsupported
method). A custom DB-backed AgentRunner is the clean end-state, but the
AgentRunner base class isn't exported at 1.62. Note left in clearThread;
revisit both on the next CopilotKit upgrade.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

frontend/src/pages/Asistente.tsx

@@ -86,6 +86,12 @@ export default function Asistente() {
       if (!res.ok) {
         throw new Error(`DELETE /chat/thread → ${res.status}`);
       }
+      // NOTE: there is no official flush for the runtime's in-memory thread
+      // store at CK 1.62 — the single-route endpoint we mount only accepts
+      // agent/run|connect|stop, info, transcribe; the threads/* router
+      // (incl. threads/clear) is a separate entrypoint this adapter doesn't
+      // serve. The BFF's connect intercept (server.ts) is what keeps that
+      // process memory from ever reaching the UI.
       // Full reload is the reliable reset: CopilotKit keeps chat state in
       // more places than agent.messages (clearing it in place left the
       // conversation rendered), while a fresh boot hydrates from the