Add a non-directory grouping container for host-discovered customizations

Summary

SkillCustomization and AgentCustomization are ChildCustomizations, so they must live under a top-level container. But the only container variants are Plugin and Directory. A host that surfaces customizations it discovered itself — grouped by a logical source/scope that is not a real watched directory and not an Open Plugins plugin — has no honest container to put them in. Please add a generic grouping container variant.

Current state in the spec (0.4.0)

• Customization (top-level) is one of Plugin / Directory / McpServer. (Skill, Agent, Prompt, Rule, Hook are ChildCustomizations only — they can't be top-level.)
• DirectoryCustomization is documented as a directory the host watches; it carries writable and a file://-style uri, and a load state.
• There is no neutral "labeled group of children" container.

The problem

To surface, say, skills/agents grouped by origin (project vs. user vs. some other logical scope) that don't correspond 1:1 to a watched directory, a host has to reuse DirectoryCustomization with writable: false and a synthesized, non-file:// uri standing in for the logical source. That's a semantic stretch: it claims a filesystem directory exists where one doesn't, and it overloads a uri that consumers may reasonably expect to be a real path.

Proposal

Add a Customization::Group (GroupCustomization) top-level variant: a labeled, non-filesystem collection of ChildCustomizations. Suggested fields:

• id — stable container id (for toggling / addressing).
• name — human label for the group/source.
• children — the contained ChildCustomizations.
• enabled — container enable/disable (consistent with Plugin / Directory).
• load — a load/diagnostic state (consistent with Directory), so a group can report its own load health, errors, and warnings.
• icons / range — optional, for parity with the other customizations.
• optionally an origin / source descriptor for the logical scope.

This models host-discovered, non-file-backed groupings honestly, and is generally useful to any host that surfaces customizations it found itself rather than from a plugin or a watched directory.

Backwards compatibility

A new top-level enum variant is additive; existing producers and consumers are unaffected until they emit or read it. (Consumers that exhaustively match on the Customization variants will need to handle the new case — standard for any new variant.)

Relationship to other proposals

• Complete the child-customization model: per-child enable/disable + a symmetric invocation matrix — child state and invocation gates.
• Add first-class model and tools fields to AgentCustomization — agent behavior configuration.

All three are independent; this one is purely about the container a host groups children under, so any combination can land in any order.

Start with the 0.4.0 Customization definition and compare the existing Plugin and Directory variants. Define the Group top-level variant around the proposed fields, then update any schema or exhaustive variant handling identified while tracing those definitions. Done means hosts can represent labeled, non-filesystem groups of child customizations without reusing DirectoryCustomization.