ReadConfigFromDir doesn't replay cosmos template-omitted defaults (e.g. pruning) — v2 advisory false-positives; gates fatal validation

[bdchatham]

Problem

ReadConfigFromDir decodes app.toml/config.toml directly (BurntSushi/toml → mapstructure), which does not replay the defaults cosmos applies in code for keys the template omits. Concrete case: the seid app.toml template emits no pruning key (only comments); cosmos defaults it to nothing at read time via Viper. So ReadConfigFromDir yields Storage.PruningStrategy == "", and Validate reports storage.pruning: unknown pruning strategy "" — on an otherwise-healthy default node.

Impact

• The v2 ConfigManager (sei-chain PLT-775, PR #3678) runs Validate as an advisory pass at boot. Today a default node logs a benign-but-noisy validation error every boot because of this gap.
• This gap is what keeps v2 validation advisory rather than fatal. Fatal refuse-on-error (the design's un-defer) cannot land until the read replays template-omitted defaults, or the false-positive would refuse every default node.
• It is a structural class, not one field: any key the template omits but cosmos defaults in code surfaces the same way.

Proposed approach

Make ReadConfigFromDir (or fromLegacy) apply the same in-code defaults cosmos/Viper applies for template-omitted keys — i.e. start from DefaultForMode/cosmos defaults and overlay the on-disk values, rather than mapping bare on-disk values (empty → invalid). Alternatively, resolve config the way the node actually boots (merged Viper view) for the validation surface.

Out of scope

• The advisory→fatal promotion itself (sei-chain generate-path PR); this issue is the sei-config read-fidelity prerequisite.

References

• sei-chain PR #3678 (v2 validate-passthrough, advisory validation)
• Design: bdchatham-designs designs/config-manager/DESIGN.md (Acceptance criteria — the fatal-validation un-defer)
• Linear: PLT-775