[jrgutier]

Summary

getUserInfo now also asks for each vehicle's mobileConfiguration.tonneauOption. Its optionId
(TON-P01 for the powered tonneau) is how the Rivian app decides whether a vehicle has a powered
tonneau cover. supportedFeatures has no flag for it.

Changes

• get_user_information: add
  mobileConfiguration { __typename tonneauOption { __typename optionId optionName } } inside
  vehicle { … }.
• schemas/gateway.graphql: add tonneauOption: VehicleMobileConfigurationOption to
  VehicleMobileConfiguration. It is nullable, unlike its four siblings, because a vehicle without
  a tonneau option may return null.
• tests/responses.py: USER_INFORMATION_RESPONSE gets a tonneauOption with optionId
TON-P01.
• test_get_user_information: captures the request and asserts the query asks for
  tonneauOption { __typename optionId optionName }.

Testing

PYTHONPATH=src pytest -q -p no:cacheprovider   # 232 passed (232 before; one existing test extended)
ruff check . && ruff format --check .           # clean
mypy src/rivian                                 # no issues in 51 source files

The extended test fails without the rivian.py change.

Notes

• The field and the check come from the Rivian Android app. Its user-vehicle model tests
  tonneauOptionId.contains(TONNEAU_POWER_OPTION_ID), with TON-P01 as that ID.
• getUserInfo is needed for setup, so if the gateway rejected the new field, setup would fail.
  This branch has not been run against the live API yet. Before this PR is marked ready, we will
  confirm on our R1T that the query is accepted and returns TON-P01.
• The integration change that uses this is a separate PR (branch up/tonneau-option-gating).