pi-ai adapter: deferLoading tools cause a hard UNSUPPORTED_CONTENT error — please degrade instead

[Willatzhang]

Running dsh 0.2.0-rc.2 with the pi-ai provider, any tool marked deferLoading: true makes the adapter throw before the request is sent:

packages/llm/llm-pi-ai/src/context.ts:129-133
function toolsOf(options: GenerateOptions): PiTool[] | undefined {
  // Deferred definitions are persisted for V4; provider loading is intentionally deferred.
  if (options.tools?.some(tool => tool.deferLoading === true)) {
    throw new LlmError('Deferred tool loading is not supported yet', 'UNSUPPORTED_CONTENT')
  }

Meanwhile the core already handles the "unsupported route" case gracefully — packages/llm/llm/src/content.ts:431-436 strips deferLoading and passes the full tool list immediately when toolUpdate === undefined:

if (toolUpdate === undefined) {
  // Unsupported routes need immediately available tools and no update messages.
  let immediateTools = tools
  if (tools?.some(tool => tool.deferLoading === true)) {
    immediateTools = tools.map(({ deferLoading: _loading, ...tool }) => tool)
  }
  return { messages: withoutDeveloperMessages(messages), tools: immediateTools }
}

So the intent ("unsupported routes get all tools upfront") already exists at the projection layer; the pi-ai adapter's hard throw defeats it at its own layer.

Suggestion: mirror the core's degradation in toolsOf — drop the throw, strip deferLoading, send the full list. Alternatively, if the throw is intentional for some Pi-side reason, documenting the provider support matrix for deferLoading would help.