Add hookMatcher support for pack-installed hooks

[bguidolim]

Phase 1: Matcher Support for Pack Authors

Context

The matcher field on HookGroup exists in the data model (for JSON round-tripping), but the engine always sets it to nil when auto-deriving hook entries from pack components. Pack authors cannot target specific tools (e.g., only run a linting hook after Edit|Write calls).

Problem

A pack that installs a PostToolUse hook for code formatting currently fires on every tool call. The author should be able to specify matcher: "Edit|Write" so it only runs when files change.

Proposed Solution

Add a hookMatcher: String? field to ExternalComponentDefinition (alongside existing hookEvent). When the engine auto-derives hook settings entries, use this value for the HookGroup.matcher field.

Example Pack YAML

components:
  - id: format-hook
    description: Auto-format on file changes
    hookEvent: PostToolUse
    hookMatcher: "Edit|Write"
    hook:
      source: hooks/format.sh
      destination: format.sh

Files to Modify

• Sources/mcs/ExternalPack/ExternalPackManifest.swift — add hookMatcher to component definition
• Sources/mcs/TechPack/Component.swift — add hookMatcher to ComponentDefinition
• Sources/mcs/Install/Configurator.swift or settings composition — use hookMatcher when creating HookGroup
• Validation: if hookMatcher is set, hookEvent must also be set
• Tests

Acceptance Criteria

• Pack authors can specify hookMatcher in component definitions
• Auto-derived HookGroup entries use the specified matcher
• Validation rejects hookMatcher without hookEvent
• Events that don't support matchers (UserPromptSubmit, Stop, etc.) get a validation warning

Reference

• Hooks reference — Matcher patterns

[bguidolim]

Closing — this shipped as part of the HookRegistration consolidation.

The final shape differs slightly from the proposal: instead of a flat hookMatcher field on ComponentDefinition, handler metadata lives in a HookRegistration struct (Sources/mcs/TechPack/Component.swift) bundling event, matcher, timeout, isAsync, and statusMessage. The YAML surface is exactly what this issue asked for — pack authors still write flat hookEvent / hookMatcher keys, mapped into the struct by a custom decoder.

Acceptance criteria:

• ✅ Pack authors can specify hookMatcher — ExternalPackManifest.swift (decode + encode).
• ✅ Auto-derived HookGroup entries use the matcher — ConfiguratorSupport.swift → Settings.addHookEntry(matcher:) → HookGroup(matcher:).
• ✅ Validation rejects hookMatcher without hookEvent — enforced at YAML decode time as a DecodingError. HookRegistration.event is non-optional, so metadata-without-an-event is structurally impossible in the internal model.
• ❌ Warning for events that don't support matchers — not implemented, intentionally. See below.

Beyond the original scope: mcs doctor verifies the matcher against the declaring component (#359), export round-trips it back to YAML, and Settings reports when two packs register the same command under conflicting matchers instead of silently dropping one. Covered by unit tests in ExternalPackManifestTests and end-to-end + drift tests in LifecycleIntegrationTests.

On the fourth criterion: the matcher is deliberately a pass-through — MCS does not interpret matcher strings, Claude Code does. Warning about events that ignore matchers would mean hardcoding an allowlist over the 22 hook events, which drifts whenever Claude Code adds one, and a stale allowlist would tell a correct pack it is wrong. If it's still wanted, the right home is a warning-only heuristic in PackHeuristics (next to the existing matcher-on-doctor-check warning) so it only surfaces during mcs pack validate — worth a separate, narrowly scoped issue rather than keeping this one open.