[SPoA/Clean Code] Classify and diagnose RuntimeOverlayActivator failures

[KeyffMS]

Audit finding

RuntimeOverlayActivator.Activate wraps profile resolution, request construction, native overlay activation and application-state transition in one catch (Exception) block. Every exception is converted into the same user-facing fault path, and this boundary does not emit the full failure through the structured diagnostics authority.

This can make a programming/contract error appear identical to an expected operational overlay failure and can discard the diagnostic context needed to correct the defect.

Target state

Define an explicit activation-failure policy that distinguishes expected runtime/native failures from invariant or programming failures while preserving safe overlay shutdown.

Use the existing Diagnostics and native failure policy rather than adding another logger.

Acceptance criteria

• Every failed activation is reported through Diagnostics with component, operation, activation mode, target handle and exception details.
• Expected operational/native failures disable the overlay, transition to Fault and show the current user-facing notification.
• Contract/invariant failures are not silently reduced to only a user message; they follow an explicit report-and-rethrow or fail-fast policy suitable for production and tests.
• Cleanup failure does not replace the primary activation exception.
• Automatic activation still records the suppressed target needed for recovery behavior.
• Tests cover expected native failure, profile/contract failure, cleanup failure and successful activation.
• Architecture documentation describes the classification boundary.