Shadows tab persistence

Part of #836. Wires the Shadows tab. Shadows is removal-only in v1; help text directs users to Site Editor → Styles → Shadows for adding/editing. Depends on the Color/foundation PR.

Scope

• ShadowsTab lifts removedDefaults to modal level.
• Payload includes removedShadowDefaults: [slug, ...] (the operational key already accepted by the endpoint and reified server-side per the endpoint sub-issue).

Acceptance criteria

• Removing a default shadow persists; reload editor confirms it's gone.
• Re-checking a removed default in a follow-up edit restores it (idempotency at the UI level).
• Standard loading / success / error UX.
• Visual verification: editor's shadow picker reflects exactly the kept shadows after save (i.e., reified custom shadows render identically to defaults).

Out of scope

• Adding / editing custom shadows (deliberate v1 cut; separate effort if needed).

References

• Tracking issue: #836
• Endpoint reification: CBT_Theme_Settings_Save::reify_shadow_removals().

Start with the ShadowsTab implementation and trace how its modal state can carry removedDefaults into the save payload, using removedShadowDefaults as the endpoint key. Read CBT_Theme_Settings_Save::reify_shadow_removals() to understand the server-side behavior. Done means removals survive reloads, re-checking restores them, standard save states work, and the shadow picker matches the kept defaults.