Support dynamic settings sections

[teal-bauer]

Summary

Adding engine-ecu to the service meant touching Config, ParseRedisSettings, and ToRedisFields — all for a struct field and a HasPrefix check. Any section.key key already carries its section name; there's no reason to maintain an allowlist.

• Replace hardcoded Config fields with map[string]map[string]interface{}
• ParseRedisSettings splits on first dot, creates sections dynamically
• ToRedisFields iterates all sections generically
• Keys without a dot are silently dropped

Existing settings (scooter.*, cellular.*, etc.) work as before. New sections don't require code changes. Includes unit tests for standard sections, arbitrary names, dotless keys, and round-trips.

[teal-bauer]

Empty sections ([cellular], [engine-ecu]) in the existing settings.toml are lost after a Redis round-trip — the old hardcoded struct wrote them unconditionally; the dynamic approach only writes sections that have keys. Shouldn't matter in practice since nothing reads the TOML directly, but worth knowing.

[teal-bauer]

Superseded by #4, which drops the Config struct entirely for map[string]map[string]interface{} and moves the unknown-section warning to schema.Has() so the allowlist is schema-driven. #3 then emits nested TOML sub-tables for dotted keys. Closing in favor of those; will port the round-trip tests separately.