[bug] Preserve distinct GeoJSON Point features with identical coordinates

Describe the bug

geojsonToNetjson deduplicates every geometry by its longitude and latitude. This is correct for shared LineString endpoints, but it silently discards distinct GeoJSON Point Features at identical coordinates, retaining only the first feature's ID, label, and properties.

This commonly occurs with OpenWISP Controller's Estimated Location feature: multiple public IP addresses can resolve to the same low-precision WHOIS point. In one production response, 142 GeoJSON Features became 31 map nodes because many estimated locations shared coordinates.

Steps To Reproduce

1. Convert a GeoJSON FeatureCollection containing two Point Features with different IDs and properties at [139.69, 35.69].
2. Inspect the resulting NetJSON nodes.
3. Observe that only the first Point Feature is present.

Expected behavior

Every Point and MultiPoint occurrence must become a distinct NetJSON node. Feature IDs and properties must be retained. Coordinate deduplication may continue for LineString and MultiLineString topology only.

Exact-coordinate Point groups must remain represented as one aggregate marker at every zoom level, because zooming cannot separate identical geometries. Clicking it should display a default overlap popup stating the count and that zoom cannot separate the points.

Extend mapOptions.nodePopup with an optional overlap-content callback that receives the shared location and child nodes. Applications can then replace the default popup without rendering every child marker.

Screenshots

Not applicable.

System Informatioon:

• OS: production environment, not available
• Node.js Version: not available
• Browser and Browser Version: Chromium, version not available

Additional context

Do not use spiderfying or point displacement as the default for large groups. They are suitable for a few points but are unreadable and expensive for around 100 colocated estimated locations.

Add tests for duplicate-coordinate Points, Point and LineString coordinate collisions, generated IDs, persistent exact-coordinate groups, the default overlap popup, and its custom callback.

Related Monitoring follow-up

We'll need to work on openwisp/openwisp-monitoring#834 to link the overlap popup to the filtered Location admin changelist.

Start by tracing the geojsonToNetjson conversion and mapOptions.nodePopup entry points, then inspect how nodes and exact-coordinate groups are represented across zoom levels. Add coverage for duplicate points, Point/LineString collisions, generated IDs, persistent groups, the default overlap popup, and the custom callback; done means all feature data is retained and grouped points expose the required popup behavior.