Implement a smooth transition between two UI states in React

You are implementing a specific UI transition in React. You pick the lightest mechanism that actually produces the described motion, not a default reach for a full animation library because it's the most familiar tool.

TRANSITION
When a card in a grid is clicked, it should visually expand into a full detail view that appears to grow from the card's position, not just appear instantly in a new location.

CURRENT CODE
A CardGrid component that renders CardPreview items, and a separate CardDetail route that currently just replaces the whole page instantly on click.

PREFERRED ANIMATION LIBRARY
Motion (formerly Framer Motion), already a dependency elsewhere in the app.

BROWSER SUPPORT REQUIREMENT
Must degrade gracefully on Safari versions that do not support the View Transition API — an instant swap is an acceptable fallback there.

SELECTION RULES
If the transition is a simple property change — opacity, transform, color — tied to a class or data-attribute toggle, implement it with a plain CSS transition and let React only toggle the class or state; do not reach for a JavaScript animation library for something CSS already animates natively and more cheaply. If the transition needs to happen while a state update or navigation would otherwise cause a jarring instant swap, wrap the state update in startTransition, or useTransition's returned function, so React can keep showing the old UI, marked as pending, until the new content is actually ready — this addresses the timing of the swap, not the visual motion itself, and should not be confused with an animation mechanism. If the transition is a genuine shared-element or cross-DOM-tree animation — an item visually morphing from a list into a detail view — and the target platform supports it per the stated browser requirement, use the View Transition API: React's ViewTransition integration if the project's React version has it, or the native browser API directly otherwise, since this is the one case plain CSS transitions and startTransition genuinely cannot produce on their own. Only bring in an external animation library when the transition involves physics-based motion — spring, drag, gesture-driven interaction — that neither CSS nor the View Transition API can model. Respect prefers-reduced-motion for any transition longer than a subtle micro-interaction, either skipping it entirely or replacing it with an instant or cross-fade equivalent for users who have opted out of motion. Prefer animating transform and opacity over properties like width, height, or top and left that trigger layout recalculation on every frame — a transition on a layout-affecting property forces the browser to recompute surrounding elements' positions on every frame, which is measurably more expensive than compositing a transform, and the visual difference is rarely worth that cost when translate or scale achieves the same motion. When combining startTransition with a CSS transition — for instance, fading in newly-committed content — attach the transition to the element that actually persists across the state change, not to a freshly-mounted element with no prior state, since a transition needs an initial and a final value on the same element to have anything to animate between.

OUTPUT FORMAT
1. Which mechanism you chose and the one-sentence reason it is the lightest fit for this specific transition, not a generic justification that would apply to any transition.
2. The implementation, as real code.
3. The prefers-reduced-motion fallback, implemented, not just described.