[KISS/SPoT] Use one immutable settings snapshot per application use case

[github-actions]

Audit finding

SettingsCoordinator.Current returns a defensive deep copy. Several use cases read it repeatedly within one synchronous operation:

• RuntimeCoordinator accesses Settings during evaluation, assignment lookup and activation.
• ConfigurationForm.RefreshProfiles reads automatic mode, applications, visual profiles and counts through separate snapshots.
• ConfigurationForm.UpdateAutomaticModeState reads the snapshot multiple times.
• VisualProfileManagerForm.RefreshProfiles repeatedly resolves Settings, including inside the profile loop.
• SightAdaptContext.ApplyApplicationState reads independent snapshots for profile and automatic-mode presentation.

This creates unnecessary allocations and can combine data from different committed generations if a synchronous settings event is introduced between reads. The snapshot is the correct consistency boundary, but callers are not treating it as one.

Target state

Each command, event handler or refresh operation captures exactly one immutable/defensive settings snapshot and passes it through all downstream reads for that operation.

Keep the existing transactional write authority in SettingsCoordinator.

Acceptance criteria

• No logical use case repeatedly calls SettingsCoordinator.Current.
• Runtime evaluation and overlay activation use the same captured snapshot.
• Form refreshes bind all controls from one captured snapshot.
• Helpers that need settings receive IReadOnlySightAdaptSettings explicitly.
• Defensive-copy behavior remains intact for external callers.
• Tests verify one coherent settings generation is used per operation.
• A regression test detects accidental repeated snapshot acquisition in critical paths.