Bug: manage_wake_subscription Zod schema silently strips harnessTargetMetadata extension fields

Summary

When calling the manage_wake_subscription MCP tool (via /ai/mcp/server/memory-core), the openapi/Zod schema validation silently strips harnessTargetMetadata extension fields (like appName, tabShortcut, etc.) if they aren't explicitly defined in the strict schema.

Context

This was discovered during the #10402 Wake Subscription Bootstrap implementation. The service-layer bootstrap() method correctly retains all fields because it reads directly from the graph (GraphService.db.nodes.get()) and calls the internal service method subscribe(), bypassing the MCP server's Zod input validation layer. However, direct tool calls to manage_wake_subscription({action: 'subscribe', ...}) or update have their harnessTargetMetadata properties stripped if they aren't matched by the schema.

Expected Behavior

harnessTargetMetadata should allow pass-through of arbitrary key-value pairs, or the Zod schema should be updated to specifically define the known extension properties (e.g., appName, tabShortcut, url, adapter, daemonSocketPath, coalesceWindow).

Steps to Reproduce

Call the MCP tool directly:

manage_wake_subscription({
    action: 'subscribe', 
    harnessTarget: 'bridge-daemon', 
    harnessTargetMetadata: {appName: 'Claude', tabShortcut: '3'}
})
// Resulting list/query returns: harnessTargetMetadata: {}

Dependencies

• Out of scope for #10402 (explicitly noted as a future ratchet). Tracked here as a separate diagnostic follow-up to prevent drift.