feat(projects): change a member's role from the member list

An invite sent with the wrong role could not be corrected. The only way
back was to remove the person and invite them again — and removing a member
unassigns every task they were responsible for, so fixing a dropdown cost
somebody their work. This is the other side of "an external user cannot
create tasks": the rule was right, the role was wrong, and there was no way
to say so.

PATCH against a membership that already exists, not the upsert AddMember
does. Somebody who is not a member is not silently made one: that is an
invite, it belongs to the invite flow, and doing it here would let a typo
in a user id add a stranger to a project without anybody being asked.

The owner is refused, with the real reason rather than the true but useless
one. Ownership lives on the project rather than in project_members, so the
plain answer would have been "not a member" — which is correct and tells
nobody anything. Ownership is transferred, not granted, and two owners is a
state with no way to settle a disagreement about who may remove whom.

In the list, the owner's standing is text and everybody else's is a
dropdown. A disabled control would be a thing that exists to say no.

And the roles are finally in Danish. The API's words are `owner`, `editor`
and `viewer`, and they were being printed straight into a Danish page; the
list now uses the same three phrases the invite form beside it already did.

The smoke test drives both browsers, because the interesting part is that
the other one's permissions really change: a viewer is told the project is
read-only and has no quick-add box, the owner promotes them from the list,
and after a reload the box is there and the notice is gone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

internal/httpapi/projects_handlers.go

@@ -502,6 +502,53 @@ func (s *Server) handleInvite(w http.ResponseWriter, r *http.Request) {
 	writeJSON(w, http.StatusCreated, inviteResponse{Link: link, Emailed: emailed})
 }
 
+type memberRoleRequest struct {
+	Role string `json:"role"`
+}
+
+// handleSetMemberRole changes an existing member between editor and viewer.
+//
+// Until now the only way to correct an invite sent with the wrong role was to
+// remove the person and invite them again — which also unassigns everything they
+// were responsible for, because removing a member clears their tasks' assignee.
+// Fixing a dropdown should not cost somebody their work.
+func (s *Server) handleSetMemberRole(w http.ResponseWriter, r *http.Request) {
+	var req memberRoleRequest
+	if err := decodeJSON(w, r, &req); err != nil {
+		return
+	}
+	projectID := chi.URLParam(r, "projectID")
+	userID := chi.URLParam(r, "userID")
+
+	role := store.Role(req.Role)
+	if !role.Valid() || role == store.RoleOwner {
+		writeFieldErrors(w, map[string]string{"role": "must be editor or viewer"})
+		return
+	}
+
+	// The owner has no project_members row at all — ownership lives on the project
+	// — so this would report "not a member", which is true and completely
+	// unhelpful. Say the real reason instead.
+	owner, err := s.db.ProjectOwner(r.Context(), projectID)
+	if err != nil {
+		s.storeError(w, "project owner", err)
+		return
+	}
+	if userID == owner {
+		writeError(w, http.StatusConflict, CodeConflict,
+			"the owner's standing cannot be changed; ownership is transferred, not granted")
+		return
+	}
+
+	if err := s.db.SetMemberRole(r.Context(), projectID, userID, role); err != nil {
+		s.storeError(w, "set member role", err)
+		return
+	}
+	s.activity(r, projectID, "", "member.role_changed",
+		map[string]any{"user_id": userID, "role": string(role)})
+	w.WriteHeader(http.StatusNoContent)
+}
+
 func (s *Server) handleRemoveMember(w http.ResponseWriter, r *http.Request) {
 	projectID := chi.URLParam(r, "projectID")
 	userID := chi.URLParam(r, "userID")