Groups: share a project with a team, including shared-update groups

[giswqs]

Summary

Add groups: share a project with a named set of people, with owner/manager/member roles, invite-only or request-to-join membership, and an opt-in "members can update each other's projects" mode for real team co-ownership.

Why

The unit of sharing today is one project and one owner. A team of five that works on the same map has no representation in the system. Their options are to pass an unlisted URL around (no membership, no revocation, no list of who has it) or to fork (five diverging copies, no way back).

Organization-wide visibility, filed separately, solves "everyone at my institution" but not "these six people". Those are different problems and both come up constantly — a research team inside a university, a working group across two departments, a semester's cohort inside a larger course.

The missing piece with real teeth is shared update. Even with group visibility, a project still has one owner who is the only person who can change it. For a team that genuinely shares a map, "only Ana can save" is the whole problem restated.

Proposal

1. Groups

• A group has a name, description, optional thumbnail, and members. Groups may live inside an organization or stand alone across accounts.
• Membership roles: Owner (one, transferable), Manager (invite, remove, moderate content), Member (view group content, contribute own).
• Joining: invitation-only, request-to-join with manager approval, or open to any signed-in user. Invitations by username or email, with pending/accepted states.

2. Share with a group

Add group targets alongside the visibility level, so a project's sharing is "visibility level, plus these groups". ShareProjectDialog.tsx grows a group picker listing the groups the signed-in user belongs to. A project may be private yet shared with one group — that is the common case and must be expressible.

3. Shared-update groups

A group flag, set at creation and not changeable afterwards (so nobody widens write access to existing content by accident): members can update projects shared with that group, not just open them. Server-enforced on the write path. In the app, a project opened from a shared-update group saves back to the original rather than forcing Save As.

This needs a conflict answer. The honest minimum for v1 is last-write-wins with a clear warning when the stored version changed since load, plus a link to the version history from #1522. Real merging is out of scope.

4. Group content browse

The Project Gallery gains a "Groups" source next to the public listing and "My projects", so a group's shared maps are browsable in-app rather than only on the website.

Scope notes

• Server-side on share.geolibre.app, mirrored in share-gallery.ts and the gallery dialog.
• Depends on real sign-in. Reuse the role vocabulary from the organizations issue and from the collaboration session's per-participant permissions (participantCanEdit() in lib/collab-protocol.ts) rather than introducing a third set of words for the same idea.
• Removing someone from a group must revoke their access to group content immediately, including any cached raw .geolibre.json URL. Say what the caching behavior is.

Effort

Wishlist.

---

Part of #1665 (access control umbrella).