Seven REVIEW(shared-instance) markers are candidates for <Instances>/InstancedMesh

What

House style rule 3 has a carve-out: a single material/geometry instance shared by many
meshes gets useMemo(() => new X()) + material={…} instead of a JSX child (JSX would
create one instance per mesh), flagged with a REVIEW(shared-instance): comment for a
human to weigh whether the scene actually wants <Instances>/InstancedMesh instead.

Seven live in the corpus:

WaterScene's 100 icosahedra sharing one geometry + one material is the strongest
<Instances> candidate of the seven — the clearest case where per-mesh draw calls are
being paid for no visual reason.

Why it matters

Performance/style polish across seven single-demo files, not a correctness bug and not
site-wide — the rule's carve-out is working as intended (each is REVIEW-flagged rather
than silently accepted). Worth tracking as a batch rather than fixing ad hoc, since
converting to <Instances> changes the component shape (data-driven instances vs. JSX
children) and is worth doing consistently if done at all.

Recommendation already on file

docs/REVIEW-QUEUE.md #8: review each of the seven for whether <Instances> is a better
fit, starting with WaterScene as the strongest candidate. Not urgent — the current code
is correct and performant, just possibly not idiomatic.

Pointer

docs/REVIEW-QUEUE.md §8 ("Shared-instance markers — is <Instances> the real answer?").
See also §9, which covers backdrop-area.tsx's variant of the pattern (N instances, one
live, picked by a leva switcher) — decided separately as "leave marked, no new rule needed
yet" since it's a single occurrence.

Start with docs/REVIEW-QUEUE.md §8, then inspect scene/backdrop-water/WaterScene.tsx:51 as the strongest candidate and compare its shared geometry/material pattern with the available Instances/InstancedMesh approach. Review the other six listed files, and mark each as converted or intentionally left as-is with the rationale recorded in the queue.