[DRY/KISS] Consolidate settings transaction plumbing across use-case facades

[KeyffMS]

Audit finding

ConfigurationUseCases and VisualProfileUseCases are intentionally thin, but they repeat the same infrastructure around SettingsCoordinator:

• storing and validating the coordinator;
• exposing a defensive snapshot;
• forwarding the Changed event;
• wrapping domain mutations in Commit;
• returning closely related commit-result shapes.

SettingsCoordinator.Commit and PersistCurrent also repeat expected-exception classification and persistence failure handling.

The duplication is small, but it is transaction plumbing rather than product behavior and is likely to spread as additional configuration use cases are added.

Target state

Introduce one lightweight reusable transaction context/helper for application use cases and one private persistence execution path inside SettingsCoordinator.

Prefer composition and private helpers. Do not create a deep use-case inheritance hierarchy or generic command framework.

Acceptance criteria

• Expected settings persistence errors are classified and formatted through one implementation path.
• Unexpected transaction failures continue to be reported and rethrown.
• Commit still publishes exactly once only after persistence succeeds.
• PersistCurrent preserves its current no-change-event behavior unless an explicit product decision changes it.
• Configuration and visual-profile use cases share snapshot/event/commit plumbing without sharing their domain commands.
• Public behavior and error messages remain unchanged.
• Tests cover success, validation failure, I/O failure and unexpected exception paths after refactoring.