Changed parts: one column in the service table, not one each

Oil & Oil filter, Engine air filter and Cabin air filter had a column of Yes/No
each in the Service history table, 375px of the 1022px table between them for
three bits of information. The form has always kept them together in one Changed
parts section, which is the honest shape: they are one answer to one question
about a service, not three unrelated readings. The table said otherwise, and the
list is going to grow - every part added would have taken another column and
pushed the table into a sideways scroll.

They are one column now, 234px with the widest summary on screen, and its width
no longer depends on how many parts exist. The cell names what was changed
rather than counting it, because a history is read down the page and "2" tells
you nothing about which two; past two names it becomes the first part and a
tally, which is what keeps one line one line as the list grows. Nothing changed
reads as an em dash.

The detail is a dropdown, not a dialog. This is read-only detail about one row
of a table you are reading down: a modal would black out the rows being compared
against and charge an open-and-close for each one. It is pinned under the button
it was opened from, closes on an outside click, Escape or a scroll - it is fixed
to a point on the screen, so a table that moves underneath would leave it
pointing at the wrong row - and there is one panel rather than one per row. It
lists every part with a Yes or a No, the unchanged ones included, so the em-dash
row still answers the question instead of being a dead cell.

One list in lib/serviceParts.js now drives the form's checkboxes, the cell's
summary and the panel. That is the point of the change as much as the width is:
adding a part was three edits that had to agree, and is now one entry plus its
boolean on the API's service_records collection. The form builds its state and
its payload from the list rather than naming the three fields twice - the save
payload is unchanged in shape, which was checked against the wire rather than by
reading it.

This walks back part of the previous commit, which had just made all three
hideable separately: the server's column set drops oil/engineFilter/cabinFilter
for a single "parts" key, and a test now asserts those three are not columns of
their own, so the table cannot drift back. A car with ["oil"] stored as hidden
would quietly get the combined column - nothing has that stored, the deployed
stack predating the feature, and stale keys are dropped on read rather than
erroring.

Verified in a browser against a stub API: all four summary cases (one part
named, two named, three as "Oil & Oil filter +2", none as an em dash); the panel
opens anchored under its button with the right Yes/No for the row, stays inside
the window, and closes on outside click, Escape, scroll and a second click,
switching rows without leaving a second panel behind; the picker offers "Changed
parts" as one entry and hiding it sends {"hiddenServiceColumns":["parts"]};
dragging sends "parts" in the order with the hidden column holding its slot; the
Edit dialog renders from the shared list and its PATCH still carries all three
booleans with the unticked one false. go vet, go test ./... and npm run build
are clean.

Not verified: no automated test covers any of it - the web app still has no test
runner, so the cases above were driven by hand. The drag and the panel were
exercised through dispatched events rather than a pointer, the browser pane not
compositing, so the native drag image and the panel's behaviour under a real
click-and-hold are unchecked. The dropdown overlaps the rows beneath it, which
is what a dropdown does but was not weighed against a taller table. The deployed
Web App still shows three columns until it is redeployed.

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

Web App/README.md

@@ -102,8 +102,8 @@ Config (`server/.env`, copy from `.env.example`):
   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) 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
+  which columns the Service history table shows (no File column for somebody who
+  keeps no receipts). 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. Two things can't be
   switched off: the Information tab, and the service Date — a history with the
@@ -125,6 +125,14 @@ 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.
+- **Changed parts** — every part a service can record sits in one column, not one
+  column each: they are a growing list and a column apiece would widen the table
+  without end. The cell names what was changed (past two, the first and a tally)
+  and opens a panel listing every part with a yes or a no — a dropdown rather
+  than a dialog, so the rows you are comparing it against stay on screen. Both
+  the column and the form's Changed parts section are driven by one list in
+  `lib/serviceParts.js`, so adding a part is one entry there plus its boolean on
+  the API's `service_records` collection.
 - **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