Fix time remapping with stretched precompositions - #427

Addresses the reproducible blank-frame case in the original attachment to #323.
The two later reports in that thread do not include equivalent assets, so this
PR does not claim to resolve them.

Root cause

When a precomposition has time remapping, lottie-flutter converts the remapped
seconds into child-frame progress and then divides that already-remapped result
by the layer's sr. In the original animation, this second operation moves the
child outside its visible content and produces blank frames.

Time-remap output already identifies child time.
lottie-web
and both Lottie iOS rendering paths
(main-thread,
Core Animation)
use that output directly and apply start/stretch calculation only when
remapping is absent.

The Lottie specification
separately says stretch is applied first when both sr and tm are present.
This PR does not change the input used to sample an animated tm; it only
removes the output-side sr division.
Lottie Android
currently retains that division, so this is an intentional compatibility
difference supported by the original asset and the web/iOS behavior.

Summary

• apply precomposition time stretch only when time remapping is absent
• treat runtime ValueDelegate.timeRemap values as direct child time too,
  without applying the layer stretch to their output
• add a focused pixel regression in which remapping selects child frame 50 and
  the old extra division incorrectly selects frame 25
• retain a no-remap control that guards against accidentally removing ordinary
  time stretch

Testing

• base plus the new test only: the remapped case failed with a transparent
  pixel instead of red; the no-remap control passed
• flutter test test/time_remapping_test.dart: 2 passed
• original issue asset at frame 130:
  • base: 0 non-transparent pixels
  • patched: 167,294 non-transparent pixels
• additional checks passed:
  • flutter analyze
  • ten selected non-golden root test files: 464 tests
  • flutter test in example: 1 test
  • flutter pub run tool/prepare_submit.dart
  • flutter build web in example

The full root flutter test run on Windows completed with 990 passed and 30
failed. Every failure was a golden pixel comparison. The tracked golden inputs
with time remapping all have an effective sr of 1, so those failures do not
exercise the changed tm plus non-unit-sr path.

This repository documents golden generation and verification for pinned Apple
Silicon macOS runners. That canonical golden run was not available locally.