Service history: columns you can switch off and rearrange

A car's page has let you choose and arrange two things for a while - which tabs
it shows, and which rows the Information tab lists, both dragged into whatever
order you like. The Service history table was left out of that: nine columns,
hardcoded, in one order, for every car. An EV shows Oil & Oil filter and Engine
air filter on every row of a history that will never record either, and a reader
who mostly wants Notes has to look past four columns of dates and distances to
reach it.

It works the way the other two do, because a third mechanism for the same idea
would be one to keep in step. Both lists are properties of the car, so everyone
it is shared with sees the same table, and both need write access to set. The
columns are stored as the hidden set rather than the visible one, so a column
added in a later release is on by default. The arrangement covers the hidden
columns too, which is what makes a column switched back on return to where it
was instead of reappearing at the end - verified below, since that is the part
of this shape that is easy to get wrong and invisible until somebody hits it.

Date cannot be switched off. Every row of that table is work done on a day, and
a history with the day taken out stops being a history; it can still be dragged
anywhere, which is exactly the rule Information already follows in the tab bar.
That is a judgment call and the annotation that prompted this only circled the
other eight columns - moving "date" into hideableServiceColumns and dropping the
filter in the picker would reverse it in two lines if it turns out to be wrong.

Server: hidden_service_columns and service_column_order on the car, validated
against their own key sets by the endpoint that already does this for tabs,
fields and readings. The arrangeable set is derived from the hideable one plus
the date rather than written out again, so the two cannot drift as columns are
added. Bootstrap appends missing fields to existing collections, so the two
columns appear on the next server start with no migration to run.

Web: the table stopped being nine hardcoded th/td pairs and is now driven by one
list of columns, head and body from the same source, which is what stops a moved
or hidden column from shifting the headings out of line with the cells. The
cells are built a row at a time rather than a call per cell, so a long history
doesn't rebuild every cell three times to read its text, its classes and whether
it is the file column. The column headings kept their existing car.services.col*
translations - the keys are mapped rather than derived, because renaming a dozen
strings in three languages to save a lookup table would be the wrong trade. Four
new strings in all three languages.

Verified: go vet and go test ./... pass, with new tests covering both key sets -
that hiding the date is refused, that a field key is not a column key, and that
the arrangeable set is the hideable one plus the date. npm run build is clean.
The page itself was driven in a browser against a throwaway stub API: the
rewritten table renders identically to the hardcoded one, switching two columns
off removed exactly those two from head and body with the rest still aligned and
sent {"hiddenServiceColumns":["oil","engineFilter"]}, dragging Notes onto Km
reordered head and body live and saved an order with the hidden columns still
holding their places, switching Oil back on returned it between Next km and
Cabin air filter rather than to the end, and a read-only share gets no gear
button, no draggable headings and no drag hint.

Not verified: the drag was exercised by dispatching drag events at the
component's own handlers, not by a pointer - the browser pane was not
compositing, which rules out both screenshots and a real drag - so the native
drag image and cursor are unchecked. No automated test guards any of the web
behaviour; the web app still has no test runner. The API rejects unknown JSON
fields, so this web build against an older API Server would take a 400 when
saving the picker: they deploy together from this repo, but one must not ship
without the other. The phone app is deliberately untouched, having no column
table to arrange, and ignores both new fields.

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

Web App/README.md

@@ -101,10 +101,13 @@ Config (`server/.env`, copy from `.env.example`):
   sections that car's page shows (connected service, service history, technical
   checks, maintenance, fuel cost, charging cost, documents, parts, reminders —
   Fuel cost off on an EV and Charging cost off on a petrol car) and which of the
-  14 Information rows it lists (no Differential oil on a car without one). It belongs to the car, so everyone it is shared with sees
+  14 Information rows it lists (no Differential oil on a car without one) and
+  which columns the Service history table shows (no Oil, no Engine air filter on
+  an EV). It belongs to the car, so everyone it is shared with sees
   the same page; setting it needs write access. Stored as the *hidden* sets, so
-  anything added in a later release is on by default, and the Information tab
-  itself can't be switched off.
+  anything added in a later release is on by default. Two things can't be
+  switched off: the Information tab, and the service Date — a history with the
+  day taken out stops being one.
 - **Locking the layout** — the padlock in the sidebar, above the theme toggle,
   holds every arrangement still at once: the garage, a car's tabs, its
   Information rows, the provider's readings. It is a guard against nudging a
@@ -122,6 +125,10 @@ Config (`server/.env`, copy from `.env.example`):
   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
   native drag events as the garage, so also pointer-only.
+- **Arranging the Service history columns** — the column headings on that tab
+  drag into any order, saved on drop, and it covers the hidden columns too. Date
+  is arrangeable although it can't be switched off, the same rule Information
+  follows in the tab bar.
 - **Arranging the connected service's readings** — the headline readings on that
   tab drag the same way. Only what the provider reported can be arranged, so a
   reading that turns up later (an EV range on a car that was parked unplugged)