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

[vishr]

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 fix(services): make persistence.mode decide storage and server persistence #79 remain unchanged.

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

[vishr]

Retitled and rewritten after measuring the current behaviour against main. The original framing — derive Redis AOF from the mode — was a subset of the actual defect.

What I measured. Rendering a service with persistence: {mode: ephemeral}:

command: exec redis-server --requirepass "$REDIS_PASSWORD" --appendonly yes
volumes:
  - ob_sample_redis_data:/data

The mode changes nothing. And it is not Redis-specific: redis, valkey, postgres, mysql, mongodb, clickhouse, rabbitmq, meilisearch, nats and minio all render a durable data volume under mode: ephemeral. persistence.mode governs volume ownership for workloads (internal/app/runtime.go:130); services never consult it.

So the durable volume is the larger defect and the hardcoded AOF is a second one on top of it.

On the override. The original rule — explicit settings win, contradictions surfaced — is kept, with the ownership split made explicit: persistence.mode owns the Onebox volume and the backup/plan gates and is not overridable by a driver flag; settings owns the server's internals and is. That keeps sensible defaults with a real escape hatch, without letting a Redis flag silently redefine what Onebox claims about data lifetime.

An explicit divergence is reported rather than refused — ob canonical shows the effective value and its origin, ob doctor names the consequence — so an operator can choose it and cannot be misled by it.

On scope. The mode-to-default derivation is small. The work is in internal/app/services.go, where driver commands are literal strings with settings appended; emitting one effective value per option makes the command computed rather than concatenated. Today an authored appendonly: no renders --appendonly yes --appendonly no.

Left open deliberately: whether every driver gains an ephemeral flag set in the first pass, or only Redis and Valkey do while the rest merely stop creating a durable volume.