Add client plugin customizations to automations

[Connor Peet (connor4312)]

Automations usually run when no client is connected, so there's no active client to supply plugins. A user can set up an automation on a machine with their plugins installed, but later runs can't use those skills, agents, prompts, or rules. This PR lets an automation carry its own copies of client plugins. Client tools are out of scope.

Protocol changes

• AutomationSessionTemplate.customizations?: ClientPluginCustomization[]: the client plugins each run should get, in the same shape clients publish in activeClients[].customizations.
• The host copies plugins when the automation is saved. On automation/createRequested or automation/updateRequested, the host copies every entry that is new or whose uri or nonce changed, reading virtual://… contents from the dispatching client with the existing server→client resource* requests. If any copy fails, the whole action is rejected.
• Unchanged entries keep their existing copy. Entries with the same id, uri, and nonce aren't re-copied, so a client that can't serve a plugin can still edit the rest of the definition by sending back the template it received.
• AutomationEntry.customizations?: PluginCustomization[]: the host-owned copies, matched to template entries by id. Each has a host uri clients can browse, plus children and load. Every run session receives them in SessionState.customizations with no clientId.
• Copies belong to one automation. Hosts may store identical copies (same uri and nonce) once and share them, which clients can't observe. Copies are never refreshed automatically: a client sends a new nonce to pick up local changes, so unattended runs use exactly what the user saved.
• AutomationCapabilities.customizations: {}: capability hosts advertise to show they support this.
• No reducer changes, because automation/set already carries the full entry.

Rust generator fix

The new round-trip fixture showed that Rust dropped "type": "plugin" when serializing a plugin outside the Customization union. This already affected activeClients[].customizations today. ClientPluginCustomization now keeps its type field, and AutomationEntry.customizations gets a serde helper (following the existing running-tool-call helper) that puts it back. This PR includes a Rust-only fix changelog fragment for it.

Other changes

• Documentation: added a Customizations section with a sequence diagram to docs/guide/automations.md, and updated the action docs.
• Fixtures: new round-trip fixture 050-automation-customizations-snapshot.json, and 043-automation-capabilities.json now includes the new capability.
• Changelog fragments for both changes.

Validation

• npm run generate and npm run test pass (451 tests, 100% branch coverage on types/reducers.ts).
• Go, Rust (tests and clippy), Swift, and Kotlin client suites pass, including the new fixture.
• .NET: 549 of 550 pass. The one failure is RealSocketTypeScriptConformanceTests, which couldn't start node inside the .NET container, so it's an environment issue rather than this change.