Add frontend support for displaying web search citations when the LLM
uses provider-native web search tools. Source parts arrive from the
backend as { type: "source", url, title } and are now rendered as
compact citation pills with favicons below the response text.

Changes:
- types.ts: Add "source" variant to RenderBlock, add sources array
  to ParsedMessageContent and StreamState
- streamState.ts: Handle "source" parts in streaming accumulator,
  deduplicate by URL
- messageParsing.ts: Handle "source" blocks in message parser,
  deduplicate by URL
- WebSearchSources.tsx: New component rendering citation pills with
  Google S2 favicons, truncated titles, external links. Shows first
  4 with "+N more" expander for overflow.
- ConversationTimeline.tsx: Render WebSearchSources in both
  historical messages and streaming output
- Fix StreamState type in tests/stories to include sources field

Updates the fantasy fork to include filtering of ProviderExecuted tool
results from message history when converting back to provider-specific
API formats. Without this, Anthropic returns an error on the second
message in a conversation that used web search:

  'unexpected tool_use_id found in tool_result blocks'

This also fixes the equivalent issue for OpenAI and Google providers.

When provider-native tool results (web search) are stored in the
database and reloaded, the ProviderExecuted flag was being lost.
This caused Anthropic to reject multi-turn conversations with:

  'unexpected tool_use_id found in tool_result blocks'

The flag was lost at three points in the persistence path:

1. chatprompt: toolResultRaw struct lacked ProviderExecuted field,
   so it was dropped during JSON marshal/unmarshal. Added the field
   with omitempty for backward compatibility.

2. chatloop: toResponseMessages() did not copy ProviderExecuted
   from ToolResultContent to ToolResultPart when converting
   in-memory results.

3. chatd: MarshalToolResult() signature updated to accept the
   providerExecuted parameter, propagated from
   MarshalToolResultContent(). Existing callers pass false.

Provider-native tools (web search) are executed server-side by the
LLM provider. The streaming response includes the tool call
(StreamPartTypeToolCall with ProviderExecuted=true) and source
citations (StreamPartTypeSource), but no StreamPartTypeToolResult.

This meant the tool call was persisted in the assistant message
with no corresponding tool result message. On the next turn, the
provider adapter's toPrompt() correctly filtered the
ProviderExecuted tool call from the assistant message, but Anthropic
still expected a tool_result for any tool_use it saw in the raw
history, causing:

  'unexpected tool_use_id found in tool_result blocks'

Fix: after streaming completes and local tools are executed,
iterate all tool calls and synthesize a ToolResultContent with
ProviderExecuted=true for any provider-executed call. This ensures
the persistence layer stores a matching tool result message. On
reload, both the tool call and tool result are filtered out by the
provider adapter.

Also propagate ProviderExecuted in persistInterruptedStep so
interrupted provider-executed tool calls get correct metadata.

Propagate the ProviderExecuted flag through the SDK type
(ChatMessagePart), chatprompt serialization (PartFromContent for
tool calls and toolResultContentToPart for tool results), SSE
streaming, and DB persistence.

Frontend filtering in both streamState.ts (live streaming) and
messageParsing.ts (page load/DB round-trip) skips tool-call and
tool-result parts with provider_executed=true, so web_search
results only render through the WebSearchSources citation pills.

…ltas

Three missing propagation points:
- db2sdk.contentBlockToPart: ToolCallContent cases were not
  setting ProviderExecuted on the SDK part, so page-load
  rendering of assistant tool-call blocks lost the flag.
- db2sdk.chatMessageParts (tool role): toolResultRow struct
  lacked ProviderExecuted, so it was dropped during JSON
  unmarshalling, and the SDK part omitted it.
- chatloop.processStepStream ToolInputDelta: published
  streaming deltas without ProviderExecuted, which could
  create a tool card before the full ToolCall arrived.

The Anthropic provider had server_tool_use and
web_search_tool_result case branches incorrectly nested inside
the tool_use case in the content_block_stop handler, making
them unreachable. This meant source citations and provider-
executed tool call/result events were never emitted during
streaming, so the frontend never received them.

Sources now appear inline at the position of the web search tool call
in the block sequence, rather than at the bottom of the message. They
use the same ToolCollapsible pattern as other tool cards (globe icon,
'Searched N results' label, chevron expander, source pills on expand).

- types.ts: add 'sources' (plural) RenderBlock variant for grouped sources
- messageParsing.ts: group consecutive source parts into inline blocks
- streamState.ts: same grouping for streaming path
- ConversationTimeline.tsx: render 'sources' blocks via renderBlockList,
  remove bottom-of-message WebSearchSources rendering
- WebSearchSources.tsx: rewrite to use ToolCollapsible with consistent
  tool card styling
- chatd.go: fix unused parameter lint warning

Instead of capturing StreamPartTypeToolResult events into a side map
and synthesizing ToolResultContent after the stream finishes, handle
them directly in processStepStream — matching how fantasy's own
agent.go accumulates provider-executed tool results (lines 1373-1391).

This removes:
- providerToolResults field from stepResult
- The post-stream synthesize loop that iterated provider-executed
  tool calls and manually constructed ToolResultContent with copied
  ProviderMetadata
- The placeholder 'provider-executed tool result' text in Result

The ToolResultContent is now appended to result.content immediately
when the stream event arrives, with ProviderMetadata carried directly
from the StreamPart.

Replace manual ProviderDefinedTool construction with the new
anthropic.WebSearchTool() helper. The helper handles arg construction
internally and will automatically pick up new options (max_uses,
user_location) as they're added upstream.