Config schema validation rejects existing inputs on Fallback components after their source module/theme is removed
### Overview After upgrading Canvas (observed `1.4.1` → `1.5.1`), saving or validating any page or template containing a component whose defining module/theme has since been uninstalled or disabled throws config schema validation errors such as `'width' is not a supported key.`. When a component's source is no longer available, its instances are converted to the `Fallback` source. The fallback's config schema for instance inputs is generated as an empty mapping, so strict config validation rejects every input key that actually exists on the instance (`width`, `columns`, …) as unsupported — even though those values are valid and must be preserved. This was originally reported together with an unrelated `LogicException` in #3591642; this issue tracks the fallback config-schema failure on its own. ### Steps to reproduce 1. Place a component instance that carries explicit inputs (for example `width`, `columns`). 2. Uninstall the module or disable the theme that defines the component, so the instance is converted to the `Fallback` source. 3. Save or validate the entity/template — every existing input key is rejected as unsupported. ### Proposed resolution `Fallback::getDefaultExplicitInput()` returns `[]`, so the fallback config-schema generator produces an empty mapping and has nothing to validate the real inputs against. Have the fallback schema generator accept the instance's actual input keys (as `type: ignore`) so existing configuration validates without data loss. ### Remaining tasks - Make the fallback config-schema generation tolerate the inputs that fallback instances actually carry. - Add regression coverage for validating a `Fallback` component instance that carries explicit inputs — no current test exercises this.
issue