`project validate` reports theme customizations broken by the target version

[lasomethingsomething]

User story

As a developer maintaining a custom theme, I want to know which theme configuration and SCSS entry points the target version removed, so that I can scope theme work before agreeing an upgrade date.

Problem

Themes fail the same way template overrides do. A removed theme.json key, SCSS variable, or mixin gives you a theme that compiles but renders wrong, or a theme:compile failure that points at core instead of at the customization that caused it.

The upgrade wizard MVP #1167 runs theme:compile inside the deployment-helper step. So theme breakage currently appears during execution, not before it. That is the point where rolling back costs the most.

An agency partner named themes as a major upgrade cost.

Implementation decisions

• New verifier tool reading each theme's theme.json and its SCSS entry points, resolved against core's theme definitions in vendor/shopware/.
• Detect three things:
  1. theme.json keys removed in the target version.
  2. Imports of core SCSS paths that no longer exist.
  3. References to removed core SCSS variables and mixins.
• Removals only. Do not guess whether a symbol that still exists changed meaning. That is not knowable statically, and claiming it would break trust in the check.
• Findings are manual, owned by the developer, with a link to the relevant upgrade note where one exists.
• Version-gated through the same determineVersionRange() path, so it works with --target-version.

Out of scope

• Rewriting SCSS or theme.json.
• Visual regression, computed-style diffing, screenshots.
• Semantic changes to symbols that still exist.
• Theme inheritance beyond what theme.json declares.

Acceptance criteria

• On 3 or more projects with custom themes that upgraded across a major version, the check reports at least 80% of the theme fixes those projects made.
• Zero false positives for removed-symbol detection, verified against core source. This check states a fact about what exists and must be right.
• Where a custom theme is present, theme findings appear before execution in 100% of wizard runs. No theme breakage first surfaces during theme:compile.

Readiness checklist

• Acceptance criteria are clearly defined.
• Backward compatibility impact addressed.
• Documentation written.
• Tests added or adjusted accordingly.