fix(app): render materialized split children like continuous features [MRXNM-82]

[agnlez]

Client feedback on the split functionality: "the features are not visualized like other features."

Split children of a continuous feature were deliberately kept out of the gradient
renderer (useContinuousFeaturesLayers), because their synthetic
${parentId}-${value} row ids had no tiles or per-PU amounts behind them. They
therefore drew as flat, fully saturated polygons from raw geometry with a black
outline, while every other feature in a non-legacy project draws as a
planning-unit-grid amount gradient — two different visual languages on the same
map.

Materialization now computes each child's own per-PU amounts, and the scenario
specification reads back the child's real feature id and amount range. That is
everything the gradient renderer needs, so a materialized child now takes exactly
the same path as any other continuous feature.

Jira story

https://vizzuality.atlassian.net/browse/MRXNM-82

What changed

• hooks/map/index.ts — useContinuousFeaturesLayers resolves a
  childFeatureId from layer settings, so gradient tiles are requested with the
  child's real feature id instead of the synthetic row id.
• target-spf/index.tsx (table eye toggle) — materialized children with their
  own amounts route through selectedContinuousFeatures; child rows also take
  their own ramp colour instead of inheriting the parent's, so siblings are
  distinguishable and the table agrees with the legend.
• legend/hooks/index.ts — children are bucketed by their own amount
  range rather than the parent's, so the legend swatch matches what the map draws
  (gradient once materialized, solid square while pending). The legend toggle now
  stamps the same settings as the table, ending the "colour depends on which
  control you used" divergence.
• Both solid-path toggles clear a stale stamped amountRange (null, not
  undefined — the reducer drops undefined) so a pending child can no longer
  get stuck excluded from useTargetedPreviewLayers.

Children still pending materialization keep the previous fallback: solid fill from
the parent's tiles with a property filter. A child that materializes while already
visible stays on the solid path until re-toggled.

Testing instructions

Verified against the staging API using the client's own data: project
Galapagos test 1 → scenario Baseline check (13 materialized split children).

1. Open the scenario's Features step and the map layer panel.
2. In the bottom Features legend group, toggle the eye on Habitats (an
   ordinary continuous feature). Expect a white→orange PU-grid gradient and a
   gradient legend bar labelled 0.001 – 92. Toggle it off.
3. Toggle Habitats / Abyssal hills (a split child). Expect the same PU-grid
   gradient style in a different hue, covering only the units where that habitat
   occurs, with a gradient legend bar labelled 9.763 – 92,000,000 — the
   child's own range, not the parent's.
4. Confirm the legend swatch hue matches the map fill.
5. In DevTools → Network, filter preview/tiles and re-toggle a child. Requests
   must go to /api/v1/projects/{pid}/features/{realChildUuid}/preview/tiles/...
   and return 200 — not /geo-features/...?bbox=, and never the synthetic
   {parentId}-{value} id.
6. Toggle the same child from the left-hand table row: identical result, and the
   two eyes stay in sync.
7. Each child should have a visibly different colour from its siblings.

Not exercised live: the pending (not-yet-materialized) child fallback, since every
child in that scenario is already materialized. That path is unchanged by this PR.

---

Checklist before submitting

• Meaningful commits and code rebased on staging (base branch for the
  MRXNM-82 work stream; branch is current with it).
• Update CHANGELOG file — n/a, this repo has no CHANGELOG.