customizations: redesign as a typed two-level tree

[connor4312]

Replace the opaque, plugin-only customization model with a discriminated union that distinguishes containers from the components inside them. This addresses three concrete problems with the previous design.

1. Constituent parts were a one-off. The old model bolted an agents array on the side of each customization to expose contributed agents; skills, prompts, rules, hooks, and MCP servers had no equivalent. Agents are no longer special — agent hosts publish every contributed component (under either a plugin or a directory) as a typed child of its container.

2. Non-plugin customizations didn't fit. The protocol assumed every customization was an Open Plugins package, so workspace sources like .github/skills/ had nowhere to live. Top-level entries are now Plugin or Directory. A Directory is just a folder the host watches, which is how a host can surface things like a host-global instructions folder or workspace skills without pretending they're plugins. Clients can tell a directory's "scope" from whether its URI sits inside the workspace, so no separate scope flag is added.

3. Saving customizations had no shape. A writable Directory doubles as a save target: clients persist new customizations with the existing resourceWrite command, and the host re-emits the directory with updated children.

Clients continue to publish customizations in Open Plugins format (ClientPluginCustomization, with an opaque nonce). They don't know how a given harness consumes plugins, so the host is free to re-interpret what they publish.

The new shape:

• Containers (Plugin / Directory) carry id, uri, name, load state, optional clientId, and a children array.
• Children (Agent, Skill, Prompt, Rule, Hook, McpServer) are typed leaves with optional metadata sourced from the Open Plugins component spec (descriptions, globs, hook events, etc.). Host-internal execution details (commands, env, args) stay off the wire.
• id is the protocol handle for every action; uri is the source location. Inline declarations (e.g. an MCP server embedded in a plugins.json manifest) use the containing file's uri plus a new optional range.

Actions collapse to four: customizationsChanged (full replace), customizationToggled (by id, walks both levels, client-dispatchable), customizationUpdated (upsert one container, children included), and customizationRemoved (by id, cascades). Children are always updated through their container.

Touches the type definitions, the session reducer and its fixtures, the version registry, the Swift and Rust generators (plus the hand-written reducer branches in each), and the customizations and actions guides.