Follow-ups: SDK feedback date-lockstep v ersioning & breaking-change workflow

Description

Tracking issue for improvement ideas gathered while presenting the new SDK date-lockstep versioning mechanism (ADR-0019) and the SDK compatibility handshake (MinSdkVersion / X-DotCMS-Min-SDK header) to the team. These are follow-up ideas to evaluate later — not work to implement now.

Acceptance Criteria

• Review the Breaking Change classification prompt for Backend and Frontend: SDK_BREAKING_CHANGE_CATEGORIES.md
• Evaluate whether the "Breaking Change" and "SDK Breaking Change" prompts can be unified into a single prompt that produces both labels
• Add a toast/in-app message for SDK incompatibility inside UVE (Universal Visual Editor), instead of only logging the warning to the project's console
• Add a "Minimum Compatible SDK" field to the Maintenance section (backoffice), below the dotCMS version
• Find a strategy to avoid having to manually merge the MinSdkVersion bump PR after every release

Priority

Low

Additional Context

Feedback collected after demoing the new SDK release/publication pipeline (date-lockstep versioning) to the team. This issue exists purely to track and follow up on these ideas — none of them are scoped or committed for implementation yet.

Start by reviewing docs/core/SDK_BREAKING_CHANGE_CATEGORIES.md and the ADR-0019 date-lockstep versioning context. Then examine the listed follow-ups across the Breaking Change prompts, UVE compatibility messaging, the backoffice Maintenance section, and the MinSdkVersion release workflow. Done means each idea has a defined scope and an agreed implementation plan.