fix(types): eliminate as-any gaps for serverTool mixing and fromChatMessages input

[mattapperson]

Summary

Fixes two type gaps reported against v0.4.0 (context: Slack thread) where consumers mixing tool() + serverTool() or using fromChatMessages() were forced to use as any.

Gap 1: Array<ClientTool | ServerTool> rejected narrow serverTool() results

ServerTool<T> defined config: Extract<ServerToolConfig, { type: T }>, which is invariant over T. So ServerTool<'openrouter:datetime'> did not assign to bare ServerTool (= ServerTool<ServerToolType>). Splitting the public surface:

• ServerToolBase — structural base, used as the union member of Tool.
• ServerToolNarrow<T> — narrow form, returned by serverTool<T>(). extends ServerToolBase via interface inheritance so narrow → base is nominal.
• ServerTool — now a type alias for ServerToolBase. Mixed arrays like Array<ClientTool | ServerTool> and Tool[] accept any serverTool() result directly.

Code that only used ServerTool without a type argument is unaffected. Callers that referenced ServerTool<T> (rare — was only useful for narrowing config) should migrate to ServerToolNarrow<T> or simply ReturnType<typeof serverTool<T>>.

Gap 2: fromChatMessages() output not assignable to request.input

fromChatMessages() returns models.InputsUnion, but callModel's request.input was typed FieldOrAsyncFunction<Item[]> | string — a narrower union that excluded EasyInputMessage (with a wide role union). The fromChatMessages docstring literally claims its output "can be passed directly to callModel()"; now the types match. Widened input to also accept FieldOrAsyncFunction<InputsUnion>.

Before / after

// Before — both required `as any`
const tools: (ClientTool | ServerTool)[] = [clientTool, datetimeTool]; // ❌ variance
await callModel(client, { input: fromChatMessages(msgs), ... });       // ❌ narrower

// After — no casts
const tools: (ClientTool | ServerTool)[] = [clientTool, datetimeTool]; // ✅
await callModel(client, { input: fromChatMessages(msgs), ... });       // ✅

Test plan

• pnpm --filter @openrouter/agent run typecheck — clean
• pnpm --filter @openrouter/agent exec vitest run --project=unit — 246/246, 21 files (20 runtime + 3 type-only)
• pnpm --filter @openrouter/agent exec biome check src tests — clean
• New tests/unit/consumer-type-ergonomics.test-d.ts locks in both fixes at type-level
• Migrated existing server-tool-stream-narrowing.test-d.ts fixtures from ServerTool<T> to ServerToolNarrow<T>
• Built & tested against a local consumer (serverTool mix + fromChatMessages) — both scenarios compile without as any

[mattapperson]

One consideration on the changeset classification for a type-level break.

[mattapperson]

reviewed, no issues found