Proxy: REST-fallback for remote_steering_wheel_heat_level_request

[a2105z]

Description

Fixes #136.

Problem

remote_steering_wheel_heater_request (on/off) is implemented via signed HvacSteeringWheelHeaterAction.power_on, but remote_steering_wheel_heat_level_request was missing from the proxy switch.

Observed behavior through the proxy: clients got a useless success / no vehicle action. The same request against Fleet API REST works:

curl https://fleet-api.../command/remote_steering_wheel_heat_level_request \
  -d '{"level":2}' -H "Authorization: Bearer $TOKEN"
# → {"response":{"result":true,"reason":""}} and the vehicle updates

Root cause: the current Vehicle Command Protocol protos only define:

message HvacSteeringWheelHeaterAction {
    bool power_on = 1;
}

There is no signed VehicleAction for steering-wheel heat level (state has StwHeatLevel, but no setter action). So a true end-to-end signed implementation is blocked until Tesla publishes that action. Meanwhile the proxy should not pretend the command is unsupported/no-op — it should forward to Fleet API REST, same as navigation_request and other REST-only commands.

Solution

• Map remote_steering_wheel_heat_level_request → ErrCommandUseRESTAPI so tesla-http-proxy forwards the original request to Fleet API (preserving body {"level":...}).
• Same treatment for the sibling remote_auto_steering_wheel_heat_climate_request (also Fleet-documented, also missing a signed action).
• Tests assert the proxy forwards these without opening a vehicle session and returns the Fleet API response.

Once a heat-level VehicleAction lands in the protos, we can replace the REST fallback with a real signed implementation.

@sethterashima @patrickdemers6 @agbpatro — this has been open since Jan 2024 with reporter follow-ups. REST fallback unblocks users today without inventing an unsupported signed payload.

Type of change

• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Bug fix (non-breaking change which fixes an issue)
• Documentation update

Checklist:

Confirm you have completed the following steps:

• My code follows the style of this project.
• I have performed a self-review of my code.
• I have made corresponding updates to the documentation.
• I have added/updated unit tests to cover my changes.

Test plan

• go test ./pkg/proxy/ -count=1
• ExtractCommandAction returns ErrCommandUseRESTAPI for heat_level / auto heat
• Proxy integration: forwards {"level":2} to Fleet API path and returns REST success body
• Manual: curl https://localhost:4443/.../remote_steering_wheel_heat_level_request -d '{"level":2}' updates the vehicle (same as direct Fleet API)