Cars: drag the tabs into order, and a lock for every arrangement

Two things, both about layouts you arrange by dragging.

A car's tab bar now takes a drag: the tabs reorder as the pointer crosses
them and the arrangement saves on drop — or on dragend, since a tab
released in the gap beside the bar never produces a drop and would
otherwise revert on the next load. Same native drag events as the garage
and the Information rows, so also pointer-only, and it needs write access.

The order belongs to the car, like the choice of which tabs show at all,
so everyone it is shared with sees the same bar. It is stored as the full
list of keys, hidden tabs included, so a tab switched off and back on
returns to where it was rather than to the end; a key the stored
arrangement doesn't mention — a tab added in a later release — follows
the arranged ones. Information is arrangeable although it cannot be
switched off, which is why the validation needs arrangeableCarTabs rather
than reusing hideableCarTabs; it is derived from that set so the two
cannot drift as tabs are added. tabOrder rides on the existing PUT
/api/cars/{id}/view, so a tab drag never has to resend what is hidden.
Where the page opens is unchanged: Information, wherever it now sits.

And a padlock in the sidebar, above the theme toggle, holds every
arrangement in the app still at once — the garage, a car's tabs, its
Information rows, the provider's readings. It is a guard against nudging
a layout while reading it, not a permission: it is the user's own setting
and says nothing about what anybody may edit, so locking hides your own
drag handles rather than stopping a co-owner rearranging a shared car.
Stored as dragLocked on the profile, like the theme it sits above, so a
locked account is still locked on the next device — where a folded
provider card stays one browser's reading habit. Unlocked by default, so
nothing changes until it is clicked, and while locked the grab cursor and
the drag hints go with the drag.

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

API Server/internal/api/cars.go

@@ -248,6 +248,19 @@ var hideableCarTabs = map[string]bool{
 	"fuel": true, "charging": true, "documents": true, "parts": true, "reminders": true,
 }
 
+// arrangeableCarTabs are the tabs a car's page can be rearranged into, which is
+// the hideable ones plus Information: it cannot be switched off, but there is no
+// reason it has to stay at the front. Derived from hideableCarTabs so the two
+// sets cannot drift as tabs are added.
+var arrangeableCarTabs = func() map[string]bool {
+	out := make(map[string]bool, len(hideableCarTabs)+1)
+	for key := range hideableCarTabs {
+		out[key] = true
+	}
+	out["info"] = true
+	return out
+}()
+
 // hideableCarFields are the Information rows that can be switched off — every
 // one of them, since unlike the tabs there is no row the page needs to keep.
 // Mirrors the car.info.* labels the web app renders.
@@ -295,11 +308,11 @@ func normalizeKeys(in []string, allowed map[string]bool, what string) ([]string,
 }
 
 // PUT /api/cars/{id}/view — choose what this car's page shows: which tabs, which
-// rows of the Information tab, and the order the Information rows and the
-// connected service's headline readings are laid out in. Body: {hiddenTabs?:
-// [...], hiddenFields?: [...], fieldOrder?: [...], metricOrder?: [...]}; only the
-// lists present are written, so a client can rearrange one group without
-// resending the others. Its own endpoint rather than fields on the car edit, so an ordinary
+// rows of the Information tab, and the order the tabs, the Information rows and
+// the connected service's headline readings are laid out in. Body: {hiddenTabs?:
+// [...], hiddenFields?: [...], tabOrder?: [...], fieldOrder?: [...],
+// metricOrder?: [...]}; only the lists present are written, so a client can
+// rearrange one group without resending the others. Its own endpoint rather than fields on the car edit, so an ordinary
 // save of the car form — which sends every other field — can never reveal
 // something somebody deliberately switched off. Needs write access: the choice
 // belongs to the car, so it is the same permission as editing it.
@@ -307,6 +320,7 @@ func (s *Server) updateCarView(w http.ResponseWriter, r *http.Request) {
 	var in struct {
 		HiddenTabs   *[]string `json:"hiddenTabs"`
 		HiddenFields *[]string `json:"hiddenFields"`
+		TabOrder     *[]string `json:"tabOrder"`
 		FieldOrder   *[]string `json:"fieldOrder"`
 		MetricOrder  *[]string `json:"metricOrder"`
 	}
@@ -341,6 +355,18 @@ func (s *Server) updateCarView(w http.ResponseWriter, r *http.Request) {
 		}
 		payload["hidden_fields"] = fields
 	}
+	if in.TabOrder != nil {
+		// A wider set than the hidden tabs: Information is arrangeable although it
+		// cannot be switched off. A partial list is accepted, and the tabs it
+		// leaves out follow the arranged ones — which is what puts a tab added in
+		// a later release at the end rather than in the middle of somebody's bar.
+		order, err := normalizeKeys(*in.TabOrder, arrangeableCarTabs, "tab")
+		if err != nil {
+			writeError(w, http.StatusBadRequest, err.Error())
+			return
+		}
+		payload["tab_order"] = order
+	}
 	if in.FieldOrder != nil {
 		// The same key set as the hidden fields, since every Information row can
 		// be moved. A partial list is accepted rather than demanding all 14: the