motion: Keep cubic-bezier anticipation and overshoot in Easing

[costajohnt]

Closes #3401

Description

Easing::sample for Easing::CubicBezier went through the shared solver that clamps its output to [0, 1], so CSS curves with control points outside that range lost their anticipation and overshoot (e.g. cubic-bezier(0.175, 0.885, 0.32, 1.275) never passed 1).

• crates/base/src/animation.rs: the solver body is now pub(crate) fn unclamped_cubic_bezier (input t is still clamped, output isn't). The public cubic_bezier wraps it with .clamp(0.0, 1.0), so its signature and output are unchanged for the existing callers. Removed the comment saying GPUI asserts easing deltas stay in [0, 1]: gpui-pre 0.3.8 with_easing only debug_assert!s that the value is finite.
• crates/base/src/motion/easing.rs: only the CubicBezier arm uses the unclamped solver; the keyword presets keep the clamped one (their control points are all in range anyway).
• crates/component/src/dialog/dialog.rs: the Fade/FadeSlide entrance now clamps easing.sample(delta) before with_easing, because that value drives the dialog opacity and shadow alpha.

This touches gpui-base because that is where the clamp lives.

Same exposure elsewhere, not changed here to keep this to one thing: resizable.rs (handle opacity on easing_move), input/group.rs (border/background colour on easing_move) and plot/hover.rs (hover progress on easing_enter/easing_exit) feed a theme easing straight into alpha or colour. The default theme curves stay in [0, 1], and these paths could already go out of range with Easing::Custom; happy to follow up with call-site clamps if you want them.

The change was written with an AI coding assistant; I reviewed and tested it.

Public API

No signatures change. Behaviour change:

• gpui_base::motion::Easing::sample — for Easing::CubicBezier with control points outside 0..=1, the output can now leave [0, 1]. Clamp at the call site when the value drives opacity or colour. gpui_base::animation::cubic_bezier still returns values in [0, 1].

Breaking Changes

• Code that relied on Easing::sample staying within [0, 1] for an out-of-range cubic-bezier curve now sees overshoot:

- let alpha = easing.sample(delta);
+ let alpha = easing.sample(delta).clamp(0., 1.);

How to Test

• New test cubic_bezier_easing_keeps_anticipation_and_overshoot (crates/base/src/motion.rs, css_timing_tests) uses the curves from the issue: (1.0, -0.4, 0.35, 0.95) samples below 0 at 0.2 and (0.175, 0.885, 0.32, 1.275) above 1 at 0.8; progress -1 and 2 still map to 0 and 1. It fails on main.
• cargo test -p gpui-base --lib (1325 passed), cargo test -p gpui-base -p gpui-component --tests (all pass, incl. 661 gpui-component lib tests), cargo clippy -p gpui-base -p gpui-component --all-targets -- --deny warnings and cargo fmt --all --check clean.

Checklist

• I have read the CONTRIBUTING document and followed the guidelines.
• Reviewed the changes in this PR and confirmed AI generated code (If any) is accurate.
• Passed cargo run for story tests related to the changes. (Not run; the default theme curves stay within [0, 1], so the story's dialogs render the same.)
• Tested macOS, Windows and Linux platforms performance (if the change is platform-specific) (not platform-specific)