Remove `any` from public types

[joshuaellis]

A clear and concise description of what the feature is

Tighten the consumer-facing TypeScript surface — replace accidental any on public types (hook return values, handler arguments like onChange, the values read off a spring) with accurate types, so the API describes what it actually accepts and returns. Scope is any that leaks into user code, not the deliberate variance any the engine relies on internally.

Two examples in the code today, both in packages/core/src/types/props.ts:

// Every lifecycle callback is `any` — handler arguments are unchecked
export interface ReservedEventProps {
  onStart?: any
  onChange?: any
  onRest?: any
  onDestroyed?: any
  // …
}

// Reserved animation/transition props are `any`, including the render prop
export interface ReservedProps extends ReservedEventProps {
  to?: any
  from?: any
  config?: any
  enter?: any
  leave?: any
  children?: any
  // …
}

Why should this feature be included?

Accidental any on public surfaces silently switches off type-checking for consumers: no autocomplete, no error when the shape is wrong, no editor guidance. It's a recurring source of user-reported bugs:

• [bug]: Incorrect result type in SpringValue onChange handler #2183 — onChange receives the wrong (any) result type.
• [bug]: render prop within <Spring> is inferred to any #2006 — <Spring> render prop is inferred as any (breaks under noImplicitAny).
• Type definition for onDestroyed is wrong #1114 — onDestroyed type definition is wrong.
• [Typescript] Type inference fails when useTransition styles are set via functions #1483 — useTransition inference fails when styles are set via functions.

Tightening these makes the real public type surface explicit and gives consumers accurate IntelliSense and call-site errors.

[joshuaellis]

Diagnosed this against the current v11 line with a type-level test harness (vitest --typecheck).

The four linked examples no longer reproduce

#2183 — the type is already correct (result.value is number); the remaining symptom is runtime (value reads undefined mid-animation), not an any type leak.
#2006, #1114, #1483 — resolved by the v11 rewrite (verified with type-tests against the public surface).

One real any leak remains: per-key event handlers

The per-key object form of an event handler infers its result as any:

useSpring({ x: 0, onChange: { x: result => result.value /* any */ } })

The single-function form (onChange: result => …) is correctly typed, and the type definitions are fine — with an explicit ControllerProps<{ x: number }> annotation the same handler types result.value as number.

Root cause is a TypeScript limitation: a callback written inline in the same object literal that useSpring's generic Props is inferred from cannot be contextually typed from that still-inferring generic, so the param degrades to any. Dropping the UseSpringProps any-branch and NoInfer were both tried and neither works — a fix needs the hooks to separate state inference from handler typing, which is an API-shape change.

The spec.ts type tests are stale

packages/core/src/types/__tests__/{common,interpolate}.ts are excluded from tsc and run by no project. Wired up, they fail against current types — interpolate now returns Interpolation rather than SpringValue, and several PickAnimated expectations no longer hold (ForwardProps still passes). Reviving them means updating the expectations and confirming the PickAnimated changes were intentional.