fix(config): let a UI read config from a newer daemon

[hyperb1iss]

Held as a draft until 0.7.0 ships. It is ready for review now.

A web UI that is older than the daemon it talks to loses its whole Settings surface. The UI decodes GET /api/v1/config into HypercolorConfig, and every config section type carried #[serde(deny_unknown_fields)], so the moment a daemon gains a config key (daemon.state_history_generations most recently) the older UI's fetch fails with unknown field and nothing in Settings loads. That happens to anyone running a remote UI against another computer's daemon, and it happened on the owner's own dev stack, where a stale UI build logged the failure on every socket open. After this PR, clients decode the daemon's config tolerantly, and every authoritative source (the config file, startup overlays, REST writes) still refuses a key it does not model, now naming it by its full path.

What this changes

• The deny_unknown_fields attribute is gone from the 13 config section types and SessionConfig, so the plain Deserialize impl that clients use skips fields it does not know.
• Two new strict decoders, HypercolorConfig::deserialize_strict and deserialize_section_strict (in the new hypercolor-types/src/config/strict.rs), decode through serde_ignored, collect every key the derive skipped, and refuse the document with a message such as unknown config keys `daemon.prot`, `rendering.servo_gpu_import.mdoe` .
• Every authoritative path goes through them: ConfigManager::parse_toml (the only path from hypercolor.toml, used by load, reload, and the daemon's startup parse), dotted overlays in config/sources.rs, both decodes in the daemon's REST config writes, and the config registry's section validator.
• REST config writes (PUT and PATCH /api/v1/config/keys/{key}) still answer 422 validation_error, now with the key path.
• The root extensions map and driver settings maps were already open and still accept arbitrary keys.

Why

The repo's agent guide (CLAUDE.md) asks clients to consume tolerant subsets of daemon payloads. The strictness exists for a reason: a typo in hypercolor.toml should fail loudly instead of vanishing on the next rewrite. That rule belongs to the loaders, so this PR moves it there. A strict-config cargo feature gating deny_unknown_fields was considered and rejected: serde behavior that depends on a feature can change silently when Cargo unifies features across crates.

Found while rehearsing the demo film against a live rig.

Verification

• Added or updated tests
• Added or updated docs (README, AGENTS.md, relevant spec, or guide)
• just verify passes locally (Rust fmt + lint + test)
• just deny passes (required for dependency or license changes)
• just ui-test and just ui-build pass (required for crates/hypercolor-ui/)
• just sdk-lint, just sdk-check, and just sdk-build pass (required for sdk/)
• just python-verify passes (required for python/)
• just compat-check passes (required for data/drivers/vendors/*.toml)
• just docs-build passes (required for docs or README changes)
• cd docs && zola check passes (required for docs link/content changes)
• Packaging scripts were syntax-checked (required for scripts/ or packaging/)
• just e2e-build passes with the normal Servo stack (required for daemon/UI/effect integration changes)
• just e2e-build-cpu passes when validating the CPU smoke fallback
• just e2e passes against the Servo stack (required for end-to-end behavior changes; starts daemon/browser)
• Tested on real hardware, simulator, or e2e harness (describe below)

The full just verify gate runs the daemon suite in parallel, which deadlocks on GPU tests on this machine, so the gates ran per crate instead:

Check	Result
cargo test -p hypercolor-types	668 passed, including the new client-tolerance and strict-path tests
config_tests, config_sources_tests, config_persistence_tests (core)	pass
daemon api_tests filtered to config_, single-threaded	38 passed, including PUT and PATCH rejection with the key path and no write to disk
clippy -D warnings on types, core, daemon (--all-targets)	pass
cargo check --workspace and the UI --lib check for wasm32-unknown-unknown	pass
cargo deny check, cargo fmt --check	pass

The UI's own code did not change (its decode becomes tolerant through the shared types), so just ui-test and just ui-build did not run; only its lockfile gained serde_ignored. The client regression test decodes a config payload carrying invented future keys in the daemon, audio, rendering, and session sections and checks the known values survive. An independent review audited every Rust file that references the config types for a remaining lenient authoritative path and found none; the one regression it raised (the registry validator) is fixed in the last commit.

Notes for reviewers

• The error text changes from serde's "unknown field x, expected one of ..." to the dotted key path, so the list of valid fields no longer appears. Nothing in the repo matched the old text.
• The serde_ignored crate cannot see keys inside #[serde(flatten)] or untagged and internally tagged content. The config graph only flattens open maps today; a future closed struct placed behind one would lose strictness without a test failing.
• A decoder outside this repo that wants strictness must call the strict helpers.
• Not changed here: PATCH /api/v1/config/keys/session?live=false with {"not_a_real_key": null} still returns 200, because the merge treats null as "remove this member" and the unchanged-value check returns before any decode. The API response envelope types (ApiResponse, ResponseMeta) still deny unknown fields too, which is the same version-skew bug one level up. Both are tracked separately.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}