ACP desktop drops CallToolResult._meta before MCP App notification

**Describe the bug**

Goose Desktop's ACP chat path drops the MCP server's non-routing `CallToolResult._meta` before delivering `ui/notifications/tool-result` to an MCP App.

The app receives `content` and `structuredContent`, but `_meta` is reconstructed from Goose's MCP App routing fields only. This breaks MCP Apps that intentionally pass view-private per-call data in `_meta`.

This has the same externally visible symptom as #7435/#7476, but IIUC occurs at a different location. The prior fix covered the legacy desktop path, the current ACP path performs two lossy reconstructions.

---

**To Reproduce**

1. Register an MCP App tool whose result contains a generic namespaced canary:

```ts
return {
content: [{ type: "text", text: "Canary" }],
structuredContent: { present: true },
_meta: { "example.com/canary": { present: true } },
};
```

2. In the View, record the result delivered to `app.ontoolresult`.
3. Ask the model to invoke the tool in Goose Desktop v1.46.0 or current `main`.
4. Observe that `structuredContent.present` is available, but `_meta["example.com/canary"]` is absent. `_meta` contains only Goose-derived app routing fields.
5. As a control, invoke an app-visible server tool with `app.callServerTool()`. That direct `tools/call` path does preserve the server `_meta`.

The behavior also reproduces deterministically in current source:

- `crates/goose/src/acp/server/tool_calls/conversion.rs::trusted_update_meta()` builds a new ACP `_meta` containing only the trusted Goose routing carrier.
- `ui/desktop/src/acp/adapter/tools.ts::toolResultValue()` builds a new `CallToolResult._meta` containing only `mcpAppMetadata(update)`.

A namespaced canary assertion fails independently at each boundary.

---

**Expected behavior**

For a model-initiated MCP App tool call, the View should receive the server's non-routing `CallToolResult._meta` through `ui/notifications/tool-result`, alongside Goose's trusted routing metadata.

The stable MCP Apps specification defines the notification params as the standard MCP `CallToolResult` and demonstrates `_meta` preserved in the Host-to-View notification:
https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/2026-01-26/apps.mdx#2-tool-result-via-uinotificationstool-result-notification

ACP permits custom `_meta` on `ToolCallUpdate`, so the intermediate transport can carry this data:
https://agentclientprotocol.com/protocol/extensibility

---

**Screenshots**

Not applicable; this is a structural result comparison.

---

**Please provide the following information**

- **OS & Arch:** macOS arm64
- **Interface:** Desktop UI
- **Version:** v1.46.0 and current `main` (`403fcc84c78e5676197219071f4740497fdd4af3`)
- **Extensions enabled:** A local generic MCP App canary
- **Provider & Model:** Provider-independent

---

**Additional context**

Version history is consistent with the regression being related to ACP adapter. v1.39.0 preserves `_meta`, v1.40.0 drops it.

- [x] I verified this does not duplicate an existing open issue.