feat(projects): sektioner kan trækkes op og ned, og båndet står ikke længere skævt

Rækkefølgen af sektioner *er* planen — "Planlægning" står før "I gang", fordi det
er den vej arbejdet går — og indtil nu kunne den kun laves om ved at slette en
sektion og lave den igen, hvilket smider dens opgaver ud i det usektionerede
område på vejen.

Hele overskriften er håndtaget. En sektionsoverskrift indeholder ikke noget, der
selv bliver trukket, så der er ingen geste at stjæle — hvilket er grunden til, at
sidebjælkens rækker skulle have et greb, og grunden til at disse ikke skal. Ikke
draggable mens den omdøbes: et draggable element lader ikke markøren vælge tekst
i det felt, det indeholder.

Serversiden er hele listen på én gang som projekter og grupper, og af samme
grund: et projekt har en håndfuld sektioner, så 0, 1, 2 … er én lille transaktion
uden præcision at løbe tør for, og en liste kan ikke ende halvt anvendt.
`ReorderSections` er scopet til projektet og ikke til en ejer — en sektion har
ingen ejer, den hører til et projekt, og om du må rykke rundt er et spørgsmål om
det projekt, som handleren allerede har stillet. Id'er fra et andet projekt
springes over af WHERE-klausulen; der er en prøve på præcis det, fordi ingenting
ellers kontrollerer id'erne enkeltvis.

Båndet stod fire pixels skævt. Det var trukket ud med --s2 og polstret med --s3 —
samme idé gjort med to forskellige tal — så det blev otte pixels bredere end
listen i hver side, og teksten landede fire pixels uden for den kolonne, rækkerne
holder. Til venstre var det usynligt. Til højre var det Omdøb og Slet, der stod
fire pixels forbi alt over og under sig, hvilket er præcis langt nok til at ligne
en fejl og ikke langt nok til at se hvorfor. En række er `.row` med
`padding: var(--s2)` inde i en boks uden, så båndet har nu samme polstring og
ingen margen.

Board-visningen er ikke rørt: der er kolonnerne vandrette, og det er en anden
geste.

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

internal/httpapi/projects_handlers.go

@@ -356,6 +356,34 @@ func (s *Server) handleCreateSection(w http.ResponseWriter, r *http.Request) {
 	writeJSON(w, http.StatusCreated, sectionJSON{sec.ID, sec.ProjectID, sec.Name, sec.SortOrder})
 }
 
+// handleReorderSections sets the order of the sections inside one project.
+//
+// Under /projects/{projectID}/ rather than beside the other section routes, which
+// hang off a section id: the thing being changed here is the project's list, not
+// any one section in it. That also puts it behind the same project permission
+// check as everything else in this subtree, instead of resolving a section to its
+// project one id at a time and hoping they all named the same one.
+func (s *Server) handleReorderSections(w http.ResponseWriter, r *http.Request) {
+	var req reorderProjectsRequest
+	if err := decodeJSON(w, r, &req); err != nil {
+		return
+	}
+	// The same ceiling as the projects list, and a bound on the transaction rather
+	// than an opinion about how many sections a project may have.
+	if len(req.IDs) > 500 {
+		writeFieldErrors(w, map[string]string{"ids": "at most 500 at a time"})
+		return
+	}
+
+	projectID := chi.URLParam(r, "projectID")
+	if err := s.db.ReorderSections(r.Context(), projectID, req.IDs); err != nil {
+		s.internal(w, r, "reorder sections", err)
+		return
+	}
+	s.activity(r, projectID, "", "section.updated", nil)
+	w.WriteHeader(http.StatusNoContent)
+}
+
 // sectionAccess resolves a section to its project and checks the caller may edit
 // it. Sections have no permissions of their own — they belong to a project, and
 // that is where access is decided.