Evaluate EventResolverBase decomposition for architecture and performance

[jschick04]

ContextEventResolverBase.cs is 1103 LOC with 4-5 distinct responsibility groups identified during the architecture alignment audit against the solution-architecture playbook:

1. Template parsing — GetOrParseTemplateDataNodes, DoesTemplateMatchPropertyCount variants, WildcardWithNumberRegex
2. Description formatting — FormatDescription, ResolveDescription, BuildNoMetadataFallbackDescription, CleanupFormatting, buffer management
3. Task/keyword resolution — ResolveTaskName, TryResolveTaskNameFromDetails, CacheTaskName, GetKeywordsFromBitmask
4. Legacy dispatch — GetModernEvent, TryDisambiguateLegacyMessage, GetParametersForDescription
5. Event model construction — CreateEventModel, ResolveEvent

Evaluation needed

• Performance: This is hot code on the read path. Evaluate whether decomposition introduces measurable overhead (virtual dispatch, additional allocations, indirection).
• Architecture: The class uses inheritance (EventResolverBase). Facade pattern is awkward with inheritance — evaluate alternative decomposition strategies (composition, strategy extraction, static helpers).
• Testability: Template-matching logic (DoesTemplateMatchPropertyCount triplet) currently lacks isolated unit tests. Decomposition would unlock testing these independently.
• Panel findings: Architecture panel was split — duck recommended splitting now (4-5 responsibility groups, hot code path), opus recommended deferring (inheritance makes facade awkward, working code).

Acceptance criteria

• Benchmark current resolver performance as baseline
• Evaluate decomposition approaches (composition vs inheritance vs static helpers)
• Assess regression risk vs testability gain
• Decision: split now, split with specific approach, or defer with documented rationale