feat(services): expose effective persistence settings in canonical and doctor

Inizia dai punti di ingresso canonical e doctor, quindi traccia il modo in cui vengono rappresentati la modalità di persistenza e i parametri dei driver per Redis e Valkey. Confronta i defaults allineati con impostazioni esplicitamente divergenti, incluse le conseguenze sulla durata della conservazione dello storage, e verifica lo stesso modello di report per gli altri driver derivati dalla modalità. Il lavoro è completato quando canonical mostra la modalità dichiarata, i valori effettivi e le relative origini; doctor spiega le divergenze senza modificare il rendering a runtime né i gate di transizione di #79.

Status

The runtime defect originally reported here was fixed by #79 (7f94af0):

• persistence.mode: ephemeral creates no durable Onebox volume for every managed driver;
• Redis and Valkey receive ephemeral persistence defaults;
• explicit driver settings override mode-derived server defaults exactly once;
• omitted and durable modes retain durable storage semantics;
• destructive persistence transitions remain gated.

Remaining problem

The override is effective but not visible enough. ob canonical and ob doctor do not explain when authored driver settings diverge from the persistence mode. An operator can deliberately enable AOF on ephemeral storage, for example, but Onebox does not state that the data survives a process restart and not a container recreate.

Scope

• Show the declared persistence mode and effective server persistence values with their origin in canonical output.
• Have doctor name actionable divergences between the mode and explicit driver settings.
• Document that persistence.mode owns Onebox storage lifetime while settings owns server internals and cannot create a durable Onebox volume.
• Report divergence; do not refuse a deliberate override.

Acceptance

• Redis and Valkey cover mode defaults and explicit overrides in canonical output.
• Doctor distinguishes a harmless aligned setting from a divergent one and explains the operational consequence.
• Other drivers with mode-derived persistence options follow the same reporting model.
• Runtime rendering and transition gates from #79 remain unchanged.

The original measurements and design discussion remain in this issue history and in #79.