cms: doctor only compares section keys, so new props on an existing section drift silently

[JonasJesus42]

Context

Same /cuida parity work as #343. Of the five sections shipped, three were extensions of sections that already existed on the account:

• BannerFull gained overlay (the hero copy box)
• ElectroluxServices gained variant, titleHighlight, footerLink, and external on each item

The gap

schemaDrift() in src/cms/schema.ts compares $componentKey lists only:

const remote = publishedComponentKeys(schema);   // just the keys under sections.items.anyOf
const missingOnAccount = local.filter((k) => !remote.includes(k));

So for those three, doctor was green the whole time — BannerFull and ElectroluxServices were already published, just at their old shape. Authoring overlay or variant: "compact" before the upload would have hit exactly the failure the module docstring warns about:

Committing content that uses it then succeeds and renders nothing, which is the worst failure mode available: silent.

Only the two brand-new sections tripped the check. The prop-level drift was invisible, and I only knew to upload because I had written the code.

Proposal

Extend the comparison one level down. The published schema already carries each component's full properties object at sections.items.anyOf[], and the repo side is cms/faststore/components/cms_component__*.jsonc — so both sides are already on disk / already fetched.

✗ landingPage: ContactChannels, SplitPromo — in the repo, not on the account.
✗ BannerFull: property `overlay` in the repo, not on the account.
✗ ElectroluxServices: properties `variant`, `titleHighlight`, `footerLink` in the repo, not on the account.

Worth flagging required changes too — going from optional to required on a published prop invalidates existing entries, which is the opposite direction and equally silent.

Caveat on implementation: the repo files are JSONC with trailing commas, and localComponentKeys() deliberately scans rather than parses to avoid a JSON5 dependency. Prop-level comparison probably does need a real parse, so that trade-off gets revisited.