StencilJS dist-custom-elements output target missing versioned registry entries for safe rollback after prop schema changes

Context

The dist-custom-elements output target emits a single bundle per component and registers each custom element under a flat name in window.customElements. When a component's public API—props, events, or slots—changes in a breaking way, the new definition overwrites the previous one without any version identifier in the registry or the generated file names.

Problem

Consumers that have cached the earlier bundle or that rely on the prior prop types receive no build-time warning. At runtime they encounter mismatched property types or missing events, and a rollback requires manually redeploying the previous bundle and clearing every client cache. Stencil does not ship a schema registry, compatibility layer, or CI integration that verifies the rolled-back artifact matches the consumer's expected contract.

Open questions

1. What minimal metadata (e.g., component hash, semantic version, or API fingerprint) could be embedded in the custom element definition or the generated .d.ts files to make a mismatch detectable at load time?
2. Is there an existing Stencil plugin or hook point that would allow a CI step to compare the current component JSON snapshot against a stored baseline and fail the build on breaking changes?
3. If external tooling (API Extractor, semantic-release, consumer contract tests) is required, what is the recommended integration pattern that keeps the dist-custom-elements output unchanged for consumers while still providing rollback verification?