P2: Consolidate tool protocol and storage metadata ownership

[lovasoa]

Audit split from #363/#366. Priority: P2.

Current-code check

This still exists in the latest code.

Tool metadata has multiple active sources:

• client-data/tools/manifest.js defines tool ids, wire codes, capabilities, toolbar visibility, shortcuts, stored tags, shape flags, updatable fields, and live schemas.
• individual tool modules also export toolId, contract, liveMessageFields, batchMessageFields, requiredCapability, and UI/runtime behavior.
• client-data/tools/index.js merges manifest metadata, tool contracts, and module exports, with module/contract fields overriding manifest fields.
• server-rendered toolbar visibility uses manifest.js, while socket validation and persistence use the merged tools/index.js definitions.

Why it matters

A tool can render with one capability/schema/shortcut/stored contract but validate or persist with another. This is especially risky for new tools because changes may pass one path while silently drifting in another.

Expected direction

• Choose one source of truth for protocol/storage/capability metadata.
• Make toolbar rendering, socket validation, persistence, and client registry consume that same source.
• Keep UI interaction code in tool modules, but avoid duplicating wire/storage/capability contracts there unless generated or checked against the source.
• Add drift tests that fail when manifest and runtime contracts disagree.