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