`project validate --target-version` scans code against a Shopware version you have not installed

[lasomethingsomething]

User story

As a developer, I want to validate my project against a future Shopware version, so that I can estimate the work before I change composer.json.

Problem

Every verifier tool takes its version range from the installed constraint. determineVersionRange() sets MinShopwareVersion from require.shopware/core, and internal/verifier/rector.go picks its ruleset with fmt.Sprintf("shopware-%s.0.php", config.MinShopwareVersion[0:3]). Twig fixers gate on the same range.

So today the tools answer one question: is my code valid for the version I already have. If you are green, the answer is always yes.

The only way to find out about the next version is to bump the constraint, run composer update, and see what breaks. That is the expensive step developers want to plan before, not during.

This also fills a gap in the wizard MVP #1167. Its preparation gate is Composer resolution plus Store API extension compatibility. An agency partner told us this is the part they can already do themselves. The risk they cannot see is in their own code.

Implementation decisions

• Add --target-version <constraint> to project validate and extension validate. It overrides the constraint passed to determineVersionRange().
• Only the upper bound moves. MinShopwareVersion stays at the installed version, so version-gated fixers fire for the range in between.
• Validation still runs against the installed vendor/. No download, no network.
• Print the effective version range in every reporter header, so the finding set is never ambiguous.
• In the wizard, show a custom-code row next to the existing extension queue, using the status vocabulary already defined in Implement local Shopware upgrade wizard flow #1167.
• Custom-code findings are informational. Composer resolvability stays the only gate, as Implement local Shopware upgrade wizard flow #1167 specifies.

Out of scope

• Downloading or installing the target version.
• --target-version for fix and format.
• Blocking an upgrade on custom-code findings.

Acceptance criteria

• On 3 or more projects that completed a 6.6 → 6.7 upgrade, running --target-version 6.7 against the pre-upgrade commit reports at least 80% of the PHP and Twig changes those projects actually made.
• Scan finishes in under 60 seconds on a project with 50k lines of custom code.
• The reported version range appears in the output of all six reporters.

Readiness checklist

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