Preserve per-item ResourceContents._meta in vMCP

Part of #5743. Surfaced in jhrozek's review of #6180.

Problem

The spec puts _meta on ResourceContents items too (it's the MCP-UI carrier), and mcpcompat models it (mcpcompat/mcp/resources.go), but vMCP drops it: vmcp.ResourceContent has no Meta field, so both the Legacy conversion (pkg/vmcp/conversion/content.go, ToMCPResourceContents/ConvertMCPResourceContents) and the Modern rebuild (pkg/vmcp/client/client.go modernReadResource) lose it. Legacy and Modern are equally blind, so there's no revision fork — but a backend that sets per-item meta (e.g. MCP-UI payloads) has it silently stripped.

Work

1. Add Meta map[string]any to vmcp.ResourceContent (pkg/vmcp/types.go).
2. Populate it in both client paths (Legacy legacyReadResource via conversion.FromMCPMeta on each item; Modern rebuild similarly).
3. Forward it in the Serve-path conversion, with the same reserved-key strip every other egress gets (mcpparser.StripReservedMeta via conversion.ToMCPMeta) — a backend can smuggle reserved io.modelcontextprotocol/* keys at the item level too.
4. Extend the meta-preservation tests to cover per-item meta on both revisions.

Related: #6027 (result-level resource _meta, shipped in toolhive-core v0.0.38 + #6180).

Start with vmcp.ResourceContent in pkg/vmcp/types.go, then trace legacy conversion in pkg/vmcp/conversion/content.go and modernReadResource in pkg/vmcp/client/client.go. Check legacyReadResource and the existing meta-preservation tests first. Done means per-item metadata survives both client revisions and Serve conversion, with reserved keys stripped on egress.