Add drive_state endpoint to vehicle_data

[Optic00]

This adds drive_state to the supported endpoints values of GET /api/1/vehicles/{vin}/vehicle_data, primarily to expose the odometer so that downstream consumers like evcc can read it over BLE. Companion PR for the evcc vehicle template: evcc-io/evcc#31743.

Changes

• drive_state added to ExceptedEndpoints and mapped to vehicle.StateCategoryDrive (the existing drive alias keeps working).
• New DriveStateFromBle converter, modeled on ChargeStateFromBle. Mapped fields: timestamp, shift_state (oneof converted to "P"/"R"/"N"/"D"; SNA/Invalid/unset become an empty string), speed (prefers speed_float, falls back to the older integer speed field via the oneof presence accessors), power, odometer.
• odometer is converted from the protobuf's hundredths-of-a-mile field to miles. Note: the Fleet API historically returns the odometer in vehicle_state, but the BLE protocol delivers it in DriveState, so it is exposed here (documented in a code comment).
• Heading/GPS are deliberately not included; the BLE protocol carries them in LocationState, not DriveState.
• README: drive_state documented as requestable via the endpoints parameter; the default response (no parameter) is unchanged (charge_state + climate_state).
• Unit tests: table-driven coverage of all shift_state oneof arms, odometer conversion including the unset case, and the speed fallback.

Example response (?endpoints=drive_state)

{"response": {"result": true, "response": {"drive_state": {"timestamp": 1752345600, "shift_state": "", "speed": 0, "power": 0, "odometer": 17720.11}}}}

Testing

• go build ./... and go test ./internal/api/models/... pass.
• Verified end-to-end against evcc's tesla-ble template (soc/status plus the new odometer) using an API-compatible shim in front of an ESPHome BLE bridge; the odometer read over BLE from a real vehicle matches the car's displayed value. I could not exercise this proxy's own BLE stack against the car, since my key pairing lives on the ESPHome device.
• Heads-up: TestAllExceptedCommandsImplemented in internal/tesla/commands panics on a nil *vehicle.Vehicle already on current main; that failure is pre-existing and unrelated to this change.