RES-1863: draggable map for group location fine-tuning

[edwh]

Re-implements #637 (RES-1863, draggable map for group create/edit) from scratch on the current codebase. The old branch was 1,240 commits behind and conflicted with the build system; it also bundled the Mapbox geocoder switch, which belongs to RES-1858 (#644) and is deliberately not included here.

Since #637 was written, develop gained a static GroupLocationMap preview and Google Places autocomplete, so this PR is much smaller than the original:

• GroupLocationMap becomes draggable: the marker is pinned to the map centre; dragging emits update:lat/update:lng. A fresh geocode from the location field still recentres the map, with an epsilon guard so the parent echoing a drag back down doesn't fight the user. A partials.dragmap hint invites the fine-tune.
• GroupAddEdit syncs the dragged coordinates and includes lat/lng in the create/edit payloads (string-cast — the store's FormData builder drops falsy values, which would eat a 0 coordinate). The :id-based remount hack is removed; it would have destroyed the map on every drag.
• API v2 POST /groups and PATCH /groups/{id} accept optional lat/lng (validated numeric, in range, both-or-neither), which take precedence over the server-side geocode of the location text. Country still comes from geocoding, or from the existing record when the location text is unchanged. With an explicit pin, an ungeocodable location string is no longer fatal — the pin wins and the country is left null.

Testing

• New GroupLatLngOverrideTest (6 tests): client coordinates win on create and edit; geocode fallback unchanged without them; out-of-range rejected; ungeocodable-location-with-pin succeeds; unchanged-location edit keeps existing coords.
• New GroupLocationMap.test.js (5 tests): drag emits updates, marker follows, external geocode recentres, echo-guard, hint text.
• Full Groups suite green (88 tests / 974 assertions); full Jest suite green (30 tests); translations check green (key added to en/fr/fr-BE only, per repo convention).

[sonarqubecloud]

Quality Gate passed

Issues
7 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Preview: https://restarters-pr-895.fly.dev

✅ Ready - restore and migrations succeeded.

• Password-protected test environment (usual dev gate password); commit 41c7f1074d7983f484515a8572b6820772e7a122 merged with develop.
• If you see a "warming up" page, give it a few minutes - it refreshes itself.
• The preview database is refreshed on every deploy and may reset at any time; anything you create here is disposable.
• Emails go to shared Mailpit, never to real recipients. Image uploads are disabled.
• The app suspends when idle; the first request after a pause can take a moment.

[ngm]

This is a good one for the testing group to test - I'll share it with them.

[ngm]

@edwh

Some feedback from user testing:

1. Drag behaviour is counter-intuitive

• Currently, dragging moves the map and the pin, and the pin jumps to the centre of the map when finished.
• This was unintuitive - expectation was to drag the pin/marker itself to a new location on the map, rather than drag the map itself to move the pin.
• Is there UX rationale for the current map-dragging approach vs marker-dragging approach? Happy to learn it if so.
• If map-dragging is the chosen style of interaction, perhaps we could consider adding some kind of 'crosshair' or indicator showing at least where the pin will land when the drag ends.

2. Odd zoom behaviour

• Zooming with the mouse wheel moves the pin on the map, i.e. changes the location of the pin; zooming with the +/- buttons does not.
• Ideally the pin should stay at its geographic location during both zoom methods.

3. No way to pan the map without moving the pin

• Panning the map (e.g. to explore a nearby area) currently moves the pin's location too, because of the map-dragging approach.
• Might be of use to have a way to pan/explore the map while the pin stays put at its geographic position.
• Though, understand that this control is for fine-tuning the marker, not initial placement, so maybe we don't expect much panning to happen.

4. Initial zoom level seems too far out

• Example: the Ulverston group has a specific street address, but the initial map shows a very wide view of the whole area.

• Perhaps we should be zoomed in closer to the currently selected address on load?

5. Help text styling and placement

• "Map marker not quite right? Feel free to drag around and fix it." is rendered larger than other help texts on this form.
• It also sits above the map; might feel more natural below it. But leave this for now until played with the other changes.

Having it such that dragging the map pans the map and the pin in the viewpoint, but doesn't move the actual pin location; and such that dragging the pin moves the pin's actual location (i.e. amends the lat/lng); might fix 1, 2, 3. Would be worth a try, unless there's good argument against it.

[edwh]

Thanks @ngm, useful feedback. There wasn't a strong UX reason for dragging the map: pinning the marker to the centre was just simpler to build. Your suggestion is better, so I've switched to it (d574d6f):

1. Drag behaviour: you now drag the pin itself, and wherever you drop it becomes the group's location.
2. Zoom: zooming (mouse wheel or +/−) only changes the view. The pin stays where it is on the map.
3. Panning: dragging the map just pans, so you can look around without moving the pin.
4. Initial zoom: the map now opens zoomed in close on the address (street level) instead of the wide view.
5. Help text: now a small grey hint below the map, like the form's other hints, and it says what to do: "Pin not quite in the right place? Drag it to the right spot." Happy to tweak once people have tried it.

The preview will rebuild with these changes, so the testing group can try it at https://restarters-pr-895.fly.dev once it's redeployed.

[ngm]

@edwh Brilliant, thanks, this feels much nicer. Have deployed preview and reshared with the testers.

One note: when trying to actually save a group, I get the error 'Group could not be edited'. Don't know if that's just a preview deployment issue, or a bug.

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud