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/tools/jobs.ts

@@ -1,13 +1,46 @@
-import type { ToolSet } from "ai";
+import { tool, type ToolSet } from "ai";
+import { z } from "zod";
 import type { TeacherToolContext } from "../tools.ts";
 
 /**
- * Async sub-agent job tools — W2 workstream (research; W6 adds demo + visual).
- * CLIENT-SIDE semantics (no execute): the turn ends with the part pending, a
- * background runner fulfills it, and the client continuation resumes the
- * teacher. See src/core/contracts.ts "THE ASYNC PROTOCOL" — read it first.
+ * Async sub-agent job tools (W2: research; W6 adds demo + visual).
+ * CLIENT-SIDE semantics (no execute) — exactly like quiz/ask: the tool call
+ * streams to the browser in `input-available` state and the server turn ends
+ * there. chat-handler's onFinish spawns a background runner that fulfills
+ * the part server-side; the client polls /api/jobs and the continuation
+ * resumes the teacher with the result as a normal tool output.
+ * See src/core/contracts.ts "THE ASYNC PROTOCOL".
+ */
+
+export const researchInputSchema = z.object({
+	question: z
+		.string()
+		.describe("The single research question to answer. Make it specific — the researcher sees nothing else of the lesson."),
+	context: z
+		.string()
+		.optional()
+		.describe("Why you need this / what the lesson needs it for — focuses the brief. One or two sentences."),
+});
+
+export const researchTool = tool({
+	description:
+		"Dispatch a background web-research agent: fact verification, current data, or niche specifics you are not certain about. " +
+		"The call is ASYNC — your turn ENDS here, so say everything you want to say first; the research brief arrives later as " +
+		"this tool's output and the lesson resumes from it. Cite the brief's sources when you use them. " +
+		"NEVER use it for things you know cold, internal reasoning, or math.",
+	inputSchema: researchInputSchema,
+});
+
+/**
+ * Per-request job tool registry. Context-free for now (the runner resolves
+ * everything from the chat record by toolCallId) — the ctx parameter keeps
+ * the createTeacherTools factory shape stable for W6's demo/visual tools.
  */
 // eslint-disable-next-line @typescript-eslint/no-unused-vars
 export function jobTools(ctx: TeacherToolContext): ToolSet {
-	return {};
+	return {
+		research: researchTool,
+	};
 }
+
+export type ResearchInput = z.infer<typeof researchInputSchema>;