fix(mu-core): tolerate the [dialogue] config section owned by mu-dialogue

[tcovert-c137]

What

Hotfix for a live incident my #482 caused: [dialogue.presence] landed in the shared ~/.config/mu/config.toml (owned/read by mu-dialogue), but mu-core's Config uses deny_unknown_fields — so every mu-core consumer (mu ask, daemon, orchestrate) rejected the entire file and silently ran on built-in defaults (no MCP servers, no providers). Found by another cc session when config-defined providers stopped loading (blocked mu-vneb).

Fix: Config gains an opaque dialogue: Option<toml::Value> passthrough — the co-resident section is tolerated without being interpreted, everything else still populates, and deny_unknown_fields continues to hard-error on genuine typos. Regression test asserts all three properties (dialogue_section_is_tolerated_not_fatal).

Testing

• just ci green in a sprint workspace based on main (c99240b2, which reproduced the failure).
• Smoke: mu versions against the real shared config (containing [dialogue.presence]) — no CONFIG ERROR on stderr.

Small + blocking concurrent work — review when convenient.

🤖 Generated with Claude Code

https://claude.ai/code/session_019YY9xpjK6mWLJDMaYnvC6T

[tcovert-c137]

Duplicate of #485 — we raced on the same incident and shipped the identical design (opaque dialogue: Option<toml::Value> passthrough + regression test). #485 was first and its test drives the real layered Config::load path, so defer there. One nit worth porting from this PR's test if desired: an assertion that a genuinely unknown top-level section (e.g. [dialoge]) still hard-errors, proving deny_unknown_fields typo-safety survives.