MCP Apps: live widget hydration silently fails – Zod validation rejects `annotations: null` in tool-result notification; history re-mount path renders the same payload fine

### What happened?

## Summary
When a tool result contains a `resource_link` content block with optional fields serialized as `null` (e.g. `annotations: null`, `title: null`, `size: null`), the MCP Apps notification handler in Claude Desktop / claude.ai throws an unhandled Zod `invalid_union` error on `params.content[1]`. The widget never receives its tool-result data and hangs indefinitely in its default state ("Generating"). Leaving and re-entering the chat re-mounts the widget via the history path, which tolerates the same payload and renders instantly — proving the data is complete and the failure is confined to the live delivery path.

## Environment
- Claude Desktop (macOS) and claude.ai (Safari) – reproduced on both
- Server: Higgsfield official remote connector (https://mcp.higgsfield.ai/mcp) AND an independent self-built OAuth 2.1 gateway proxying the same upstream – identical behavior on both, ruling out any single server implementation
- Tool: `job_display` (returns text block + resource_link block)

### What did you expect to happen?

## Expected behavior (either/both)
1. Tolerate `null` on optional content-block fields (treat as absent), consistent with the re-mount path, OR
2. Handle validation errors gracefully: drop/sanitize the invalid block, still deliver the remaining content to the widget, surface a console warning instead of silently hanging the UI

### Steps to reproduce

1. Connect the official Higgsfield remote connector
2. Call `job_display` with any completed image job id
3. Widget renders its template, then hangs on "Generating" forever
4. Open the tool call's code view: request AND full response are already present client-side while the widget hangs
5. Leave the chat, re-enter: the same stored result now renders the image instantly

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

https://mcp.higgsfield.ai/mcp

### Error messages or logs

```shell
## Console evidence (claude.ai, widget iframe context, during hang)
Error: Uncaught error in notification handler: [
{ "code": "invalid_union", "path": ["params","content",1],
"message": "Invalid input", "errors": [ ...
{ "expected":"object","code":"invalid_type",
"path":["annotations"],
"message":"Invalid input: expected object, received null" },
{ "expected":"string","code":"invalid_type","path":["title"],
"message":"Invalid input: expected string, received null" },
{ "expected":"number","code":"invalid_type","path":["size"],
"message":"Invalid input: expected number, received null" }
...]}]
(at mcp_apps:65 — full log available on request)
```

### Additional context

## Related issues (not duplicates)
- anthropics/claude-code#52565 – same Zod-v4-null root pattern on OAuth DCR fields (fixed by server-side omission)
- anthropics/claude-ai-mcp#165, modelcontextprotocol/ext-apps#671 – same symptom family (widget never hydrates), no root cause identified; this report likely explains a subset of those

## Why this matters
Any MCP server whose serializer emits explicit nulls for optional fields will produce permanently hanging widgets in the flagship Apps UI hosts, with zero server-side error signal. Reproduced here with Anthropic's own listed partner connector (Higgsfield).

Start at the MCP Apps live notification handler and trace validation of params.content[1], using the reported job_display response with null optional fields. Compare the live delivery path with the history re-mount path, then reproduce the console error in Claude Desktop or claude.ai. Done means the widget receives the tool-result data or the invalid block is handled without silently hanging.

Scritto dal modello di indicizzazione a partire dal testo della issue.