`project validate` reports Rector-fixable Shopware API changes without modifying files

[lasomethingsomething]

User story

As a developer, I want shopware-cli project validate to list the PHP changes Rector would make, so that I can see what an upgrade needs before any tool changes my code.

Problem

internal/verifier/rector.go implements Check() as return nil. Rector only runs in Fix().

Every other verifier tool has a real Check(): phpstan, eslint, stylelint, prettier, php-cs-fixer, admin-twig, storefront-twig, symfony-xml.

So the CLI's largest body of upgrade knowledge is invisible. You cannot see it without running fix and reading the diff. CI cannot gate on it. The upgrade wizard MVP #1167 has no PHP signal to show.

This upgrade report counts 399 fluent new rewrites, 32 EntityExtension classes, 48 DAL definition files, and 13 Context factory calls in one migration. Rector handles most of this. But a developer estimating that upgrade cannot see the number in advance.

Implementation decisions

• Run Rector with --dry-run --output-format=json over config.SourceDirectories. Reuse the vendor-bootstrap and composer.json backup logic already in Fix().
• Map output into validation.Result through the check parameter. All six existing reporters then work with no changes.
• Use the Rector rule FQCN as the finding identifier, so .shopware-project.yml validation.ignore keeps working.
• --only=rector and --exclude=rector work through the existing tools.Only() path.

Out of scope

• Writing Rector rules. frosh/shopware-rector owns those.
• Checking against a version you have not installed. Tracked separately.
• Changes to Fix().

Acceptance criteria

• On 5 or more real 6.6 projects, validate --only=rector reports at least 95% of the changes fix --only=rector applies, and reports nothing that fix does not change.
• validate --only=rector runs within 1.5× the time of fix --only=rector on the same project.
• Findings render correctly in all six reporters: summary, json, github, gitlab, junit, markdown.

Readiness checklist

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