W2: async job infra + researcher sub-agent

- src/store/jobs.ts: per-job JSON store in data/jobs (create/get/update/list,
  dedup by toolCallId)
- src/agent/tools/jobs.ts: research tool — client-side (no execute), turn ends
  at the call; input per contracts ResearchToolInput
- src/agent/tools/web.ts: server-side web_search (Google CSE) + web_fetch
  (Readability/Turndown/linkedom, Jina fallback) — errors return as strings,
  never thrown into the agent loop. Deps: @mozilla/readability, linkedom,
  turndown (+@types/turndown dev)
- src/agent/subagents/researcher.ts: isolated ToolLoopAgent (web tools only,
  12-step cap), researcher prompt ported from pi
- src/agent/subagents/runner.ts: spawnPendingJobs hook + runResearchJob —
  fire-and-forget, activity line per tool call, fulfills the part in the
  LATEST chat record (output-available) before flipping job status; failure
  still fulfills the part so the teacher learns the outcome
- src/server/chat-handler.ts: onFinish spawn hook after saveMessages
- app/api/jobs/route.ts: GET ?chatId= polling endpoint
- components/artifacts/job-card.tsx + registry entry: polling activity card
  (2s) → syncFromServer on finish; research-brief card (markdown + sources)
- src/agent/prompts/20-jobs.md: research doctrine for the teacher
- tests/jobs.test.ts: store CRUD, spawn hook via scripted mock teacher,
  runner completion/failure with fake model + stubbed fetch

src/agent/prompts/20-jobs.md

@@ -0,0 +1,27 @@
+## Background research
+
+You have a `research` tool that dispatches a background web-research agent. Use it to
+outsource what you cannot reliably know yourself:
+
+- **Use it for:** facts you are uncertain about, current or fast-moving data (library versions,
+  release dates, recent events), niche specifics outside your training, and anything where
+  being wrong would poison the lesson.
+- **Never use it for:** anything you know cold, internal reasoning, or math. Do not offload
+  thinking — only facts you genuinely need verified.
+
+**The call is asynchronous and your turn ends at it.** The discipline:
+
+1. **Say your piece first.** Explain the concept, set up what you're doing and why, and tell
+   the learner roughly what you're checking — the research brief arrives later as the tool's
+   output, and the lesson resumes from there. A bare tool call with no surrounding text is a
+   failed turn.
+2. **Call with a single, specific question.** The researcher sees nothing else of the lesson —
+   give it the question plus one or two sentences of context about what you need it for.
+3. **Resume from the brief.** When the result returns, weave it into the lesson. If it
+   contradicted what you said, correct yourself openly — that's a teaching moment.
+4. **Cite the brief's sources** when you use its findings (a short "source: …" or inline link).
+   Never present researched facts as your own certainty.
+
+At most one research call per turn — don't fan out; the researcher searches multiple angles on
+its own. If research fails or is unconfigured, you'll get a failure brief: say so plainly and
+continue with what you can establish, flagging the uncertainty.