Complete VR theme migration and remove compatibility plumbing

Is your feature request related to a problem? Please describe. The incremental migration needs an explicit end state so temporary legacy compatibility paths and the old story-level testTheme interface do not remain indefinitely.

Describe the solution you'd like After the ordinary and special-case migration issues are complete, remove the local legacy compatibility entry point introduced for rollout and delete obsolete testTheme prop support from test-vr/tests/www/StoryTheme.tsx and all stories/specs.

Update DEVELOPING.md and test-vr/README.md to make the default author workflow clear: a normal VR screenshot receives legacy, light, and dark variants automatically; stable variant names are generated by the runner; only documented structured metadata suppresses a variant. Document the distinction between Recharts themes and website color mode, plus how the preview displays the three variants.

Add focused regression coverage or a CI-level safeguard that prevents reintroducing story-level theme selection for ordinary tests.

Describe alternatives you've considered Leaving the compatibility API permanently would invite future tests to bypass automatic coverage and recreate the original naming inconsistency.

Relying on informal documentation alone would make it easy for the migration to remain incomplete.

Additional context Depends on #7736 and the migration/audit issues created from that work.

Acceptance criteria:

• No ordinary VR story or spec exposes or passes testTheme.
• All maintained ordinary VR assertions run in legacy, light, and dark variants by default.
• Legacy snapshots retain their compatible no-provider semantics.
• Contributor documentation describes the default, exception path, naming, snapshot update workflow, and gallery behavior.
• The repository has no central migration exclusion list or leftover local compatibility use.