feat: @lousho/build-ai-agent/worker entry for hand-written Workers (#289)

[LinuxDevil]

Problem

A hand-written Cloudflare Worker that imports createAgent cannot bundle the package root (#289): the root barrel also exports file stores, the agent-directory loader, MCP over stdio, sandboxes and other Node-only modules, so a browser-platform esbuild fails resolving async_hooks, crypto, fs/promises, http, net, stream and friends. Only the generated Worker ever bundled, because lousho build --target=cloudflare-worker redirects those imports to shims at build time.

Fix

New public subpath @lousho/build-ai-agent/worker (src/deploy/worker.ts) exporting createAgent plus the Worker-safe surface: the whole workerSdk subset (defineTool/defineSkill/defineChannel/defineMemory, the channel factories, approval policies, Worker providers, fromAiSdk, errors), the KV stores (KVStore, KVCheckpointStore, CHECKPOINT_KV_BINDING), memoryStore, the schedule helpers (defineSchedule, handleScheduled) and serveFetch.

tsup builds it in a dedicated browser-platform config through workerEntryPlugins() (src/deploy/bundle.ts) — the same shims the adapter applies, baked into the published files — plus two new ones:

• src/deploy/shims/ollama.worker.ts: ollama-ai-provider(-v2) fails on first use (Ollama targets localhost anyway).
• src/deploy/shims/mcp.worker.ts: every @modelcontextprotocol/sdk specifier fails on first connect. An external specifier would break a user's build when the optional peer is not installed; bundling it would add ~700 KB of MCP SDK + ajv to every Worker. mcpServers is therefore unsupported from this entry — lousho build (streamable-HTTP MCP on the generated Worker) or a Node target remains the way to run MCP.

ai, zod, @opentelemetry/api and the @ai-sdk/* provider packages stay external (WORKER_ENTRY_EXTERNALS) so they resolve from the user's install and share their ai copy. The published dist/deploy/worker.* (esm + cjs + d.ts) contains no node: import and no unresolvable specifier.

Regression test

src/deploy/worker.test.ts bundles the entry with the exact plugins and externals the real build uses, for platform: 'browser', and fails if a node: import, an ollama-ai-provider specifier or a @modelcontextprotocol/sdk specifier survives in graph or output; a second test asserts the export surface.

Notes

• scripts/pack-smoke.ts unpacked cap raised 16 -> 18 MiB: [R4] Slim the npm tarball: drop test files and source map weight, fix pack-smoke #191's slimming leaves room but this entry + Cloudflare Worker target: sub-agents, schedules, channels and memory from an agent directory #298's Worker channel helpers bring the tarball to 917 entries / ~16.4 MiB / ~4.3 MiB packed (caps: 1050 / 18 MiB / 4.5 MiB).
• docs/cloudflare-workers.md gains a "Writing your own Worker" section; its snippets now import from /worker. llms.txt/llms-full.txt regenerated.
• Rebased on 95855325 (Cloudflare Worker target: sub-agents, schedules, channels and memory from an agent directory #298): /worker re-exports the expanded workerSdk (channels, memory, schedules) unchanged.

Verification

• npm run build — clean; dist/deploy/worker.{mjs,js} ~617 KB each, only ai/zod/@opentelemetry/api/@ai-sdk/* specifiers remain.
• src/deploy suite: 179 tests pass (incl. the new regression test); full suite 4230 tests pass.
• npm run pack-smoke -- --skip-build — all checks pass; all 18 export subpaths load in esm and cjs.
• npm run docs:verify-snippets (full run), npm run docs:llms:check, npm run typecheck — pass.
• esbuild repro from the issue now succeeds: a consumer Worker importing /worker bundles for platform: 'browser' with zero externals flags.

Closes #289