[KISS/SPoA] Decompose OverlaySession into primary and transient overlay collaborators

[KeyffMS]

Audit finding

OverlaySession now provides a coherent aggregate boundary, but the class still owns several independently changing responsibilities:

• primary overlay creation, retargeting and shutdown;
• native-menu tracker lifecycle;
• transient popup overlay creation and disposal;
• bidirectional target/overlay maps;
• cross-overlay exclusion-list calculation and application;
• popup synchronization ordering;
• recovery and cleanup after subordinate failures.

The aggregate is behaviorally sound, but its internal state space is growing and menu-specific changes can affect primary-overlay lifecycle code.

Target state

Keep OverlaySession as the public aggregate/facade and extract small internal collaborators, for example:

• a primary-overlay slot/lifecycle owner;
• a transient menu-overlay collection;
• an exclusion-list calculator/applier.

Prefer simple composition. Do not introduce a dependency-injection container, event bus or repository layer.

Acceptance criteria

• OverlaySession remains the single public owner of one active overlay session.
• Primary overlay lifecycle is isolated from transient popup collection mechanics.
• Menu target-to-overlay bookkeeping has one focused owner.
• Exclusion-list construction and application are independently testable.
• Existing activation, retargeting, nested-menu, close, failure-recovery and disposal behavior remains unchanged.
• Existing IRuntimeOverlay and OverlayActivationRequest contracts do not grow additional overloads.
• Architecture documentation is updated to show the internal aggregate structure.