Share links: access roles, expiry, password, and revoke

[giswqs]

Summary

Extend project sharing beyond the current unlisted / public / private visibility with access roles (view-only, comment, edit), plus optional link expiry and password protection.

Why

ShareProjectDialog.tsx today offers one axis — who can find the project (unlisted, public, private). It says nothing about what someone who opens the link can do. Every shared link is effectively the same kind of link.

That is limiting in the two directions people most often want:

• Down — "anyone with this link can look, and that's all" is the normal case for an embed or a report, and today it is only approximated with maponly and panel-hiding URL parameters, which are cosmetic rather than an access decision.
• Up — there is no way to hand someone a link that lets them give feedback. Live collaboration has per-participant view-only / can-edit overrides (setParticipantMode, Feature Request: Advanced Collaboration Controls and Interactive Session Panel #754), but that is a host-managed, session-scoped control, not a property of a shared link.

Link hygiene is also missing: a shared link is permanent and unauthenticated once created.

Proposal

1. Roles on the share

Add a role alongside visibility:

Role	Can
View	Open, pan/zoom, toggle layers, identify, export image
Comment	The above, plus add and reply to comments
Edit	Full app

View and Comment should be enforced by the app when a project is opened from a share link with that role, not merely by hiding UI.

2. Link hygiene

• Optional expiry (24 h / 7 d / 30 d / never).
• Optional password.
• Revoke an existing share, and list a user's active shares with their roles from the share dialog.

3. Alignment with existing pieces

• The Comment role only means something once anchored comments exist; sequence it after that work, but design the role enum now so it does not need a migration.
• Reuse the same role vocabulary as the collaboration session's per-participant permissions so the two concepts do not drift apart.

Scope notes

• Enforcement lives on share.geolibre.app; a client-side-only restriction is a suggestion, not a permission. Scope the server work explicitly.
• Password-protected shares must not put the password in the URL.

Effort

Small to medium client-side; the real work is the server-side access model.