feat(native): evaluate prefers-reduced-motion so motion-reduce / motion-safe work on native

[YevheniiKotyrlo]

Problem

The native runtime evaluates prefers-color-scheme but not prefers-reduced-motion. Tailwind compiles motion-reduce:* to @media (prefers-reduced-motion: reduce) and motion-safe:* to @media (prefers-reduced-motion: no-preference), so both variants compile and then never apply on a device, whatever its accessibility setting.

A keyword value is also compared as written, so (prefers-reduced-motion: REDUCE) and (prefers-color-scheme: DARK) never match. Keywords are ASCII case-insensitive (css-values-4 §4.1), and lightningcss hands an unknown feature's ident through unfolded.

Solution

• reactivity.ts adds a reduceMotion observable. It is seeded from AccessibilityInfo.isReduceMotionEnabled() and kept live from reduceMotionChanged, as colorScheme is from Appearance. A platform without AccessibilityInfo leaves it false instead of throwing, because every media feature imports this module.
• prefers-reduced-motion: <value> is an equality against the current preference, so an unrecognised value matches neither state.
• (prefers-reduced-motion) in a boolean context is true under reduce and false under no-preference (MQ5 §12.1). fix: answer a condition the runtime cannot decide with unknown, not false #426 answers the other features in a boolean context.
• The compiler lowercases an ident value.

Tests

• src/__tests__/native/media-query.test.tsx
  • motion-reduce and motion-safe toggling both ways, composed with and, negated, as a bare boolean and with an unknown value.
  • A table of 13 queries under each motion preference in each colour scheme, as Chromium 153, Firefox 155 and WebKit 26.6 evaluate them with the preference emulated.
• src/__tests__/native/reduce-motion-init.test.ts: a missing getter, a rejecting getter and a working one with its change event.
• src/__tests__/compiler/compiler.test.tsx: the conditions motion-reduce: and motion-safe: compile to.

On main, 62 of the 90 cases in the three files fail; all pass here. Five mutations each fail their own cases: the bare feature never matching, the two values swapped, a case-sensitive ident, a seed that never applies, and another feature matching in a boolean context.

Verification

On Windows with Node 26:

• yarn lint clean
• yarn typecheck clean
• yarn test --maxWorkers=2 --coverage: 1394 passed, 4 failed. The 4 are the babel cases that also fail on main on this machine.
• yarn build clean
• yarn example expo export --platform web exported
• nothing unstaged after either build

No existing issue tracks this. I searched for reduced motion, prefers-reduced-motion, motion-reduce and motion-safe.

Known limits

• AccessibilityInfo answers asynchronously, so motion counts as enabled until the seed resolves.
• Android reports its animator duration scale rather than a reduce-motion setting ([Android] "Remove animations" setting isn't reflected when using AccessibilityInfo react/react-native#31221).

Merge order

• fix: answer a condition the runtime cannot decide with unknown, not false #426 moves the media evaluator onto one feature lookup and three-valued logic, and makes no-preference false in a boolean context. Whichever lands second reports prefers-reduced-motion from that lookup.
• fix(native): make colorScheme.set move every reader of the scheme #415 changes the prefers-color-scheme case beside this one. Whichever lands second keeps both.

It also shares lines with #425 (__tests__/native/media-query.test.tsx, native/conditions/media-query.ts), #427 (native/reactivity.ts), #459 (native/conditions/media-query.ts); whichever lands second rebases.

Base

Re-written on main (a5002c5).

[YevheniiKotyrlo]

Device evidence — before / after

UNFIXED — Both rows paint the same — the media feature evaluates false on every device, so neither variant fires.

FIXED — Exactly one row is green. Which one tracks the OS reduce-motion setting shown above it.

before — stock 3.0.7	after — with this PR

Both frames come from the same device in the same run (Android 36 emulator, 1140×2400 @ 480dpi). before is stock 3.0.7 rather than "this build minus this PR", so one unrelated difference is visible and worth naming rather than leaving you to spot it: the compiler's inlineRem defaults to 14 and our build sets it to 16, so every rem-derived length in the before frame renders at 87.5% of the after one — smaller type, tighter spacing, a shorter probe box. That is a different fix, not this one. Read the pair as the subject moving against the control the scene renders beside it, which this PR does not change.

Each frame carries a build-probe width=<dp> line — a rem-derived box that resolves differently on a patched build. The capture harness reads it off the device and refuses to save a frame whose probe disagrees with the variant it claims, so a before image cannot silently be a second after.

[YevheniiKotyrlo]

@danstepanov — I've added before/after device captures to 19 of my 26 open PRs here. Each pair is the same device in the same run, differing only in whether the patch is applied, so the difference should be quick to eyeball.

The other seven (#390, #410, #427, #428, #429, #430, #432) have nothing visual to show — they're build, typing and resolution fixes.

No rush at all, and happy to rebase or split any of them if that makes them easier to take.