Cars: create a car from a manufacturer service, with a per-car data tab

A car can now be imported straight from the account its owner already has
with the manufacturer, and every reading that service exposes shows up on
the car's own tab. MyToyota is the first provider.

API Server — internal/api/vehicleproviders.go adds a generic layer over a
plugin that can enumerate vehicles and read data about them. Adding the
next manufacturer is one vehicleSource adapter plus a line in
vehicleSources(): no new endpoints, no Web App changes.

  GET  /api/vehicle-providers                     providers + connect state
  GET  /api/vehicle-providers/{p}/vehicles        the caller's vehicles
  POST /api/vehicle-providers/{p}/import          create a car from one
  GET  /api/cars/{id}/provider                    live snapshot for the tab
  POST /api/cars/{id}/provider                    link / unlink a car
  POST /api/cars/{id}/provider/sync               re-apply provider data

Two properties shape it. Credentials are always the caller's own, resolved
through the same global -> org -> user cascade as the integration settings,
so a shared car shows provider data only when that vehicle is on the
viewer's account — the owner's credentials are never borrowed. And upstream
shapes are not modelled: these are unofficial APIs, so the layer searches
payloads by key name for the readings worth promoting (odometer, fuel,
battery, range) and flattens the rest to dotted key/value pairs alongside
the raw JSON. A renamed field costs one blank value, not a broken page.

The Toyota gate and its wording now live in toyotaSource, so the older
/api/integrations/toyota/vehicles endpoint and the new ones cannot drift.

Manager.InvokeBatchWith shares one transient plugin instance across a batch
of actions. The tab pulls seven capabilities, and InvokeWith builds a fresh
instance per call — which for a connector that authenticates lazily means a
fresh OAuth login per call. Batching logs in once.

cars gains provider + provider_vehicle_id (schema.go and
setup-pocketbase.mjs both). carPayload deliberately omits them, so an
ordinary car edit can neither reassign the car nor break its link;
carProviderPayload writes the link on its own.

Web App — Dashboard grows an "import from service" button beside "add car",
shown only once an account is connected, opening CarImportModal: pick the
vehicle, choose what to pull (identity / fuel type / dates / odometer, all
on by default), import. ProviderPanel becomes the car's first tab, ahead of
Information, labelled with the service: headline readings, the vehicle
record, one card per capability with its raw response, and an offer to take
the provider's odometer when it is ahead of the stored one. On an unlinked
car the tab instead offers to link it, VIN-matched. Info stays the default
selection — landing on the provider tab would fire a login on every car
page view. Full en/pl/da translations.

Tests cover the payload walking, Toyota normalization, import-selection
defaults, and — through the real handler chain against a stand-in
PocketBase — that every route is registered and that a closed gate is soft
on a listing (200 + a reason the UI can show) but hard on a write (4xx, so
a caller cannot read the reply as a created car).

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

API Server/README.md

@@ -165,9 +165,16 @@ DELETE /api/integrations/anker-solix/chargers/{sn}/control/token
 POST   /api/integrations/anker-solix/chargers/{sn}/{action}
 GET    /ocpp/{serial}                  # charger dials in here (OCPP Basic auth, not bearer)
 
+# vehicle providers — create a car from a manufacturer service; per-car provider tab
+GET    /api/vehicle-providers
+GET    /api/vehicle-providers/{provider}/vehicles
+POST   /api/vehicle-providers/{provider}/import
+
 # cars + sharing
 GET    /api/cars                       POST /api/cars
 GET    /api/cars/{id}                  PATCH /api/cars/{id}   DELETE /api/cars/{id}
+GET    /api/cars/{id}/provider         POST /api/cars/{id}/provider
+POST   /api/cars/{id}/provider/sync
 GET    /api/cars/{id}/service-records  GET /api/cars/{id}/technical-checks
 GET    /api/cars/{id}/parts            GET /api/cars/{id}/fuel-entries   GET /api/cars/{id}/fuel-stats
 GET    /api/cars/{id}/maintenance      GET /api/cars/{id}/documents      GET /api/cars/{id}/reminders
@@ -190,7 +197,35 @@ annotated with an `access` field. The per-record list endpoints also accept a
 > **Gotcha:** `updateCar` rewrites **all** car columns from the payload, so a
 > `PATCH /api/cars/{id}` must send the **full** car object — omitted spec fields
 > get blanked. (The phone's odometer quick-edit sends the whole car for this
-> reason.)
+> reason.) The two exceptions are `owner` and the provider link (`provider`,
+> `provider_vehicle_id`), which `carPayload` deliberately leaves out so an
+> ordinary edit can neither reassign the car nor break its connected service.
+
+### Vehicle providers
+
+`internal/api/vehicleproviders.go` turns a manufacturer-service plugin into a car
+you can create from your own account with that service, plus a per-car tab showing
+everything the service currently knows about it. Toyota (MyToyota) is the first
+provider; adding the next one means writing a `vehicleSource` adapter and
+appending it to `vehicleSources()` — no new endpoints and no Web App changes.
+
+Two properties shape the design:
+
+- **Credentials are always the caller's.** Every provider call resolves through
+  the same global → org → user cascade as the integration settings, so a car
+  shared with someone else shows them provider data only when that vehicle is on
+  *their* manufacturer account. The owner's credentials are never borrowed.
+- **Upstream shapes are not modelled.** These are unofficial APIs. Rather than
+  hard-coding field paths, the layer searches payloads by key name for the handful
+  of readings worth promoting (odometer, fuel, battery, range) and flattens the
+  rest to dotted key/value pairs, shipping the raw payload alongside. A renamed
+  field costs one blank value instead of a broken page.
+
+`POST .../import` takes `{vehicleId, name?, include?}`, where `include` selects
+which groups to pull (`identity`, `fuelType`, `dates`, `odometer`). Omitting it
+means "everything available". `POST /api/cars/{id}/provider/sync` takes the same
+selection, and only ever moves the odometer forward — a reading that appears to go
+backwards is a stale provider, not a car driven in reverse.
 
 ## The panel (`/`)