fix(provisioning): a per-App settings section turned off is a change, and the plan says so

[windischb]

Summary

Reported from the admin UI: unticking Dedicated subdomain for this app and staging it produced a draft that showed no changes at all — while the apply happily cleared the subdomain and dropped the host route. A plan that under-reports is worse than no plan; the whole staged-save UX rests on it being true.

The bug

An App's Settings is the complete desired override — AppAdminService rebuilds the whole thing from it, so a null section clears that override and an empty subdomain drops the global host route. The planner, though, diffed it as merge-patch off a serialization using the API's WhenWritingNull option, which erases exactly the nulls that carry the intent. It affected every section, not just Origin: turning Branding, PageTheme or any other one off staged a real clear the plan reported as nothing.

SectionPolicy gains NestedReplace next to NestedPatch. A replace section is serialized a second time with nulls kept and diffed off that. Optional<T> keeps its absence — the resolver suppresses a None through ShouldSerialize, independently of the ignore condition.

Not a regression of the ADR 0024 wave: the apps section has been NestedPatch since #214, and the apply was always right. No stored draft needs fixing — the plan is recomputed on every read.

Two honesty fixes in the same screen

• The Origin checkbox is gone. It carried no information: unticking it and ticking it with an empty field produced the identical payload, so it was a second clear button next to the one the input already has — and two controls for one fact can contradict each other (ticked but empty). It also greyed the input against an "inherited" value that does not exist; a realm has a primary domain, not a subdomain to inherit. The value is the switch now, and the hint under the field says so.
• Opening an App's settings no longer invents a ChangeFeed override. The form always emitted a ChangeFeed section from its defaults, materializing an override that says exactly what no override already says (the reader falls back to disabled either way) and adding three phantom lines to every plan. No new toggle — Enable consumer change feed already is the switch. A section the App already has is kept, so switching the feed off preserves a configured retention window instead of dropping it.

Deliberately not modelled: a disabled-but-remembered subdomain. That needs a real second property and raises the question of whether a parked host keeps blocking the cross-realm uniqueness check while routing nowhere. Worth deciding on its own.

Test plan

• Turning_off_a_per_app_settings_section_shows_in_the_plan_as_the_clear_it_is — red before the fix (unchanged instead of update), green after; asserts the plan reports both clears, that the apply really drops the override and the host route, and that re-planning the cleared state is then genuinely unchanged
• Full backend suite green (825 integration + 1667 unit)
• pnpm type-check clean, de.json parses
• Browser against the dev realm: clearing the subdomain plans as Settings.Origin.Subdomain with the live value as current and no target, applying drops the origin and leaves branding intact; an App without a change feed plans only its real change; switching a configured feed off keeps 30 days / 5000 events and plans exactly one change
• CI on this PR

🤖 Generated with Claude Code