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/cartabs_test.go

@@ -77,6 +77,38 @@ func TestNormalizeHiddenFields(t *testing.T) {
 	}
 }
 
+// The tabs arrange against a wider set than they hide against: Information
+// cannot be switched off, but it can be moved off the front of the bar.
+func TestNormalizeTabOrder(t *testing.T) {
+	got, err := normalizeKeys([]string{"reminders", "info", "fuel"}, arrangeableCarTabs, "tab")
+	if err != nil {
+		t.Fatalf("normalizeKeys: %v", err)
+	}
+	assertKeys(t, got, []string{"reminders", "info", "fuel"})
+
+	// Everything the bar renders has to be arrangeable — the hideable tabs plus
+	// Information, and nothing else.
+	for key := range hideableCarTabs {
+		if !arrangeableCarTabs[key] {
+			t.Errorf("tab %q should be arrangeable", key)
+		}
+	}
+	if !arrangeableCarTabs["info"] {
+		t.Error("the info tab should be arrangeable even though it cannot be hidden")
+	}
+	if len(arrangeableCarTabs) != len(hideableCarTabs)+1 {
+		t.Errorf("arrangeableCarTabs has %d entries, want the hideable tabs plus Information", len(arrangeableCarTabs))
+	}
+
+	// A field key is not a tab key, and an invented tab is still an error.
+	if _, err := normalizeKeys([]string{"vin"}, arrangeableCarTabs, "tab"); err == nil {
+		t.Error("normalizeKeys accepted a field key as a tab, want an error")
+	}
+	if _, err := normalizeKeys([]string{"info", "nonsense"}, arrangeableCarTabs, "tab"); err == nil {
+		t.Error("normalizeKeys accepted an unknown tab in an arrangement, want an error")
+	}
+}
+
 // The arrangement of the Information rows shares the field key set — every row
 // can be moved — but not the meaning: here the order of the list is the point,
 // so it has to survive validation exactly as it was sent.