A page opens where you put its tabs

Every tab bar in the app drags into the order you want, and then all three of
them opened on a tab picked in the source anyway: "public" on Charging, "info"
on a car, "personal" in Settings. Dragging Home chargers to the front of the
charging bar rearranged the bar and changed nothing about where the page landed,
which is the opposite of what dragging it there says.

So the front of the bar is now the landing tab, everywhere. An arrangement is
already the statement of what you want to see first; it just wasn't being read
as one. Settings > Appearance overrides it per page for the case where reading
order and landing tab are two different wishes, with "First in the bar" as the
default and the meaning of no override at all.

The rule lives in one place, lib/tabs.js, because it is one rule and three
pages: the saved choice if that tab is actually on the bar, otherwise whatever
leads it. The bar it is given is the one that will really render, hidden tabs
and inapplicable ones already dropped, so a default that no longer has a button
- a tab switched off for that car, Users on a non-admin - falls back to the
front instead of opening nothing. The tab key lists moved there too, since the
picker needs all three and would otherwise have copied them.

Each page starts on no tab and keeps following the profile until the user says
otherwise, rather than guessing and then correcting itself: the arrangement and
the default both arrive with /api/me, which on a hard refresh lands after the
view has mounted. A click ends the following, and so does the start of a drag -
rearranging a bar must not pull the content out from under the pointer. In
Settings ?tab= still wins over both, since that is what /admin redirects to.

Stored as defaultTabs on the profile, one page->tab map validated per page: a
tab that exists but on another page is an error, and an empty value is stored
as an absent key so "no default" has a single representation.

Also adds charger_tab_order and charger_card_order to the PocketBase setup
script. They were never there - the arrangements of the last two commits had no
column to persist into on a freshly set-up server - and default_tabs would have
gone the same way beside them.

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

Web App/README.md

@@ -119,8 +119,17 @@ Config (`server/.env`, copy from `.env.example`):
   drop. A property of the car like the choice of which tabs show, so everyone it
   is shared with sees the same bar, and it needs write access. It covers the
   hidden tabs too, so switching one back on returns it to where it was, and
-  Information is arrangeable even though it can't be switched off. Where the
-  page opens is unchanged: Information, wherever it now sits in the bar.
+  Information is arrangeable even though it can't be switched off. The page then
+  opens on whichever tab now leads the bar — see below.
+- **Which tab a page opens on** — a bar the user dragged says what they want to
+  see first, so every tabbed page (Charging, a car, Settings) opens on the tab
+  that now leads it rather than on a fixed one. Settings › Appearance overrides
+  that per page for the case where the reading order and the landing tab are two
+  different wishes; "First in the bar" is the default and means no override.
+  Stored as `defaultTabs` on the profile ({"charging": "home", …}), so it
+  follows the user to the next device, and a saved tab that no longer has a
+  button — one switched off for that car, a Users tab on a non-admin — falls
+  back to the front of the bar. `/settings?tab=` still wins over both.
 - **Arranging the Information rows** — the rows on a car's Information tab drag
   into any order, saved on drop. Also a property of the car, and it covers the
   hidden rows too, so switching one back on returns it to where it was. Same