docs(animation): state that effects on a shared property compose

[LeadcodeDev]

Closes #322.

The decision

Compose, and write it down. Two presets on one property usually should
compose — a pulse layered on a fade_in wants the product, not the second one
winning. Switching to last-wins would change every existing scenario that stacks
two effects, and would need a second syntax to ask for the composition back.

No rendering changes, except the narrow blur fix below.

What was actually missing

resolve_props_for_effects folds each bucket through AnimatedProperties::merge,
which has always composed. Nothing about that was written anywhere an author would
look, and the doc comment that claimed the opposite — "the last effect wins" —
went with the comments in #345. So the contract was nowhere at all.

rules/animations-compose.md now states it:

Behaviour	Properties
Product	opacity, scale_x, scale_y
Sum	translate_x, translate_y, rotation, rotate_x, rotate_y
Last written	everything else

plus the grouping rule (presets resolve together, keyframes resolve together) and
the window-bounding recipe for an author who really does want one effect alone.

The blind spot is real, but narrower than it reads

The issue notes that a bucket resolving a property to exactly its neutral value is
skipped, so an animation can never take a property back.

For a composing property that is not a defect: 1 is the identity for a
product and 0 for a sum, so skipping the neutral value and applying it are the
same answer. The guard is an optimisation.
a_neutral_value_in_a_composing_property_is_a_no_op_by_arithmetic pins that.

For a last-written property it is a defect — and it applied to exactly three
fields. Every other one in the struct already rests at a negative sentinel, so
"animated to zero" wins over an earlier value. blur, blur_x and blur_y rested
at 0.0 and merged on > 0.001, so nothing could ever take an element out of a
blur an earlier bucket had put it in.

They now rest at -1.0 and merge on >= 0.0. Every reader already guards on
> 0.0, so a negative resting value reads as no blur exactly as zero did.

Tests

Five on merge directly. Restoring the > 0.001 guard fails
a_later_bucket_can_take_blur_back_to_zero:

blur is last-wins, not a product, so zero is a value and not an absence —
guarding on `> 0.001` left an element blurred for the rest of the scene

Gate

cargo fmt --all --check clean · cargo clippy --workspace --all-targets --features rustmotion/studio -D warnings clean · cargo test --workspace 1802 passed.