Honor spec-style daemon and cache config keys

[CoreyRDean]

Non-technical summary

intent now honors the daemon/cache config keys exactly where the spec says they live, so users can edit config.toml with sectioned TOML keys and have those settings actually take effect. This matters now because the previous behavior silently ignored spec-shaped keys like [daemon] enabled = false, which turns a valid-looking config edit into a no-op.

Technical summary

• taught internal/config to parse both legacy flat aliases (daemon_enabled, cache_enabled) and spec-style sectioned keys (daemon.enabled, cache.enabled plus daemon.idle_unload_after)
• updated config writing to emit spec-style dotted section keys for the known daemon/cache settings while still preserving unknown raw keys
• extended i config get/set known-key handling so daemon.enabled, daemon.idle_unload_after, and cache.enabled round-trip through the CLI instead of only through raw file edits
• added config tests covering sectioned TOML reads, legacy alias compatibility, and emitted config shape
• added a CLI smoke test proving config set/get daemon.enabled persists the spec-style key end to end
• validation: go test ./internal/config/... ./internal/cli/..., go test ./..., go vet ./..., make build
• breaking changes: none intended; legacy flat aliases remain readable for compatibility

Additional notes

Trade-off: generated config now uses dotted TOML keys (daemon.enabled = false) rather than the older underscore aliases, which is semantically equivalent to the sectioned TOML shown in the spec and keeps the file machine-editable without widening this change into a broader config-format rewrite.

Deferred: I did not normalize every raw dotted key into explicit TOML table blocks; the only goal here was to close the spec/implementation gap for the known daemon/cache settings without risking unrelated config churn.