Cluster bubbles ignore urgency and the app's colour language (COLOR-4)

[BurningAXE]

Problem

Map cluster bubbles are rendered in Google's default navy, which is the only
thing on the map that does not follow the app's colour language. At the zoom
the map opens at, most signals sit inside a bubble — so urgency, which pin
colour exists to communicate, is invisible for the majority of what is on
screen.

Design review finding COLOR-4 (docs/ai/DESIGN_UI_REVIEW_2026-08-25.md).

Why it is not a small fix

There is no hook for this anywhere in the Dart API.

• ClusterManager (google_maps_flutter_platform_interface 2.9.5) carries a
  clusterManagerId and an onClusterTap callback. That is the whole type.
• On Android, ClusterManagersController.ClusterRenderer overrides
  onBeforeClusterItemRendered (individual pins) and onClusterItemRendered,
  but not onBeforeClusterRendered — so the bubble comes straight from the
  Maps SDK utility library's DefaultClusterRenderer, with its built-in
  bucket colours.

So the options are to fork the plugin on both platforms, or to stop using its
clustering.

Proposed approach — Dart-side clustering

Roughly 200 lines:

• Grid-cluster the visible signals on each camera idle (_onCameraIdle
  already exists in map_page.dart).
• Draw bubbles as BitmapDescriptor.bytes from a canvas — circle plus count —
  cached by (count bucket, colour).
• Colour each bubble by the highest urgency it contains, which is strictly
  more information than a flat brand orange would be: a cluster holding an
  amber signal reads amber.
• Tap still zooms to the cluster bounds.

Risks

• Touches the recurring far-pin InfoWindow bug: reclustering tears down the
  open native InfoWindow, and the current workaround re-asserts it. A new
  clustering path has to preserve that.
• Changes clustering behaviour on both platforms, so it needs a real device
  pass rather than a widget test.

Already done

MapMarkerBuilder.clusterOf keeps SignalUrgency.red out of clustering
entirely, so a signal where an animal may die is always its own red pin at
every zoom. That is the one lever Dart has today, and it means the navy bubble
now only ever contains green and amber signals. This issue is the rest of it.

[BurningAXE]

Related: co-located signals form a cluster that can never be opened

Found while testing on the J6+ (2026-08-29). Worth folding into this issue,
because the proposed Dart-side clustering has to solve it — and the issue as
written ("Tap still zooms to the cluster bounds") would reproduce the bug.

Symptom

Tapping the navy 4 bubble at pl. Sv. Nedelya zooms the map straight to max
zoom (the + control greys out) and the bubble is still a 4. Every further
tap is a no-op. The four signals inside are unreachable — there is no way to
open any of them.

The four are at byte-identical coordinates in signals_test
(42.697435865676695, 23.32189992070198): JP3sQFOZNZXtJEhe1XZ3
(LEGACY deploy check), Ue96jIP7xLFmUei90FhN (QA merge verify 0817),
b6VZKW7Ujlx9Xow1gFx2 (CatRescue_prod), iM2d4ICAoYvMNgtJosnU
(DogRescue_prod).

Cause

Three things combine:

1. The algorithm cannot split them. google_maps_flutter_android 2.19.5
   uses the stock ClusterManager, whose default algorithm is
   NonHierarchicalDistanceBasedAlgorithm with
   DEFAULT_MAX_DISTANCE_AT_ZOOM = 100 px. The merge span is
   100 / 256 / 2^zoom in projected units, so at max zoom 21 it is ~5.5 m on
   the ground at Sofia's latitude. Anything closer never separates, and
   identical points never separate at any zoom. iOS is the same code path
   (GMUNonHierarchicalDistanceBasedAlgorithm, default 100 pt), so this is not
   Android-specific.
2. Two is enough. mMinClusterSize = 2 in this version of
   ClusterRendererMultipleItems (android-maps-utils 4.1.0), so even a pair
   of co-located signals becomes an unbreakable bubble.
3. Zooming is the app's only response to a cluster tap. _onClusterTap
   (lib/src/widgets/map_page.dart:87) does
   animateCamera(newLatLngBounds(cluster.bounds, 50)). For a co-located
   cluster bounds is a degenerate point, so this asks for max zoom — and once
   there the handler has nothing left to do. No fallback, no spiderfy.

MapMarkerBuilder.clusterOf keeping SignalUrgency.red unclustered is why red
pins escape this. Green and amber ones do not.

Not only a test-data artifact: two people reporting the same stray from the
same spot, or one reporter filing twice, lands inside 5 m routinely.

Suggested fix

Cluster carries markerIds (= signal ids), so the map already has what it
needs today, before any of the rendering work here. In _onClusterTap: compute
the bounds' ground span; if it is below the ~6 m that max zoom can resolve (or
the camera is already at max zoom), open a bottom sheet listing the cluster's
signals — reusing the existing signal-card row — instead of animating the
camera. Otherwise zoom as now.

That fixes both platforms in one place and needs no custom renderer, so it can
land independently of COLOR-4. Whichever way round they are done, the Dart-side
clustering needs the same escape hatch: a grid clusterer has exactly the same
"cell never splits" property for identical coordinates.