refactor(vehicle): adopt shared tesla-protocol package

[Bre77]

Intent

Retarget python-tesla-fleet-api to consume the published tesla-protocol PyPI package (Teslemetry/tesla-protocol, generated as tesla_protocol) as its source of Tesla protobuf definitions, replacing the vendored proto/ sources and generated tesla_fleet_api/tesla/vehicle/proto/ modules this repo previously mirrored. Goal: single source of truth - the API client already adopted the npm sibling package (@teslemetry/tesla-protocol), so this brings the Python library onto the same shared package. Verified before switching: tesla-protocol requires protobuf<7,>=6.32.0 and stamps gencode 6.31.1, both compatible with Home Assistant core's protobuf==6.32.0 pin (a hard blocking constraint since HA core depends on this library). All internal imports rewritten from tesla_fleet_api.tesla.vehicle.proto.X_pb2 to tesla_protocol.command.X_pb2 across the library, tests, and scripts/ble-harness; deleted proto/, tesla_fleet_api/tesla/vehicle/proto/, tools/regenerate_protos.sh, and createProto.sh since they are now redundant. No public API change - this is purely an internal source swap. During migration, discovered tesla-protocol 0.4.0 shipped generated .pyi stubs with a bug (bare, unresolvable cross-file imports caused by a protoc-pyi-generator vs protoletariat alias mismatch) that broke pyright strict mode on 14 lines in commands.py, with zero runtime impact (all tests passed). Rather than mask this with local pyright-ignore suppressions, fixed it at the source: opened and shipped Teslemetry/tesla-protocol#13 fixing the generator script and the checked-in stubs. That fix released as tesla-protocol 0.5.0, so the dependency floor here is bumped to >=0.5.0 and pyright is now clean with zero errors. Version bumped to 1.7.7 (separate commit per repo convention) since this is a released-quality dependency swap, not just an internal refactor. Full test suite (375 tests), ruff check, ruff format, and pyright strict all pass.

What Changed

• Replace vendored Tesla protobuf sources and generated bindings with the shared tesla-protocol>=0.5.0 PyPI package, updating library and test imports accordingly.
• Preserve existing tesla_fleet_api.tesla.vehicle.proto imports through compatibility aliases while removing the obsolete generation scripts and checked-in definitions.
• Bump the package version to 1.7.7 and refresh protobuf dependency metadata and documentation.

Risk Assessment

✅ Low: The follow-up restores the legacy protobuf import namespace with thin upstream re-export shims while preserving tesla-protocol as the single source of definitions; no material defects were found in the full diff.

Testing

Inspected the complete migration, ran targeted compatibility and command-path tests plus the full 376-test suite, demonstrated consumer serialization through tesla-protocol 0.5.0, and repeated the signed-command envelope check under Home Assistant’s exact protobuf 6.32.0 runtime; everything passed and no UI evidence was applicable because this is an internal Python-library dependency swap.

Evidence: Consumer protobuf round-trip

tesla_fleet_api=1.7.7 declared_dependency=tesla-protocol>=0.5.0 installed_tesla_protocol=0.5.0 protobuf_runtime=6.33.6 tesla_protocol_gencode_stamp=6.31.1 legacy_import_same_class=True round_trip_lock_state=VEHICLELOCKSTATE_LOCKED result=consumer import, compatibility import, serialization, and parsing succeeded

tesla_fleet_api=1.7.7
declared_dependency=tesla-protocol>=0.5.0
installed_tesla_protocol=0.5.0
protobuf_runtime=6.33.6
tesla_protocol_gencode_stamp=6.31.1
new_import=vcsec_pb2.VehicleStatus
legacy_import_same_class=True
serialized_vehicle_status=1001
round_trip_lock_state=VEHICLELOCKSTATE_LOCKED
result=consumer import, compatibility import, serialization, and parsing succeeded

Evidence: Home Assistant protobuf 6.32.0 compatibility

protobuf_runtime=6.32.0 tesla_protocol=0.5.0 commands_imported=tesla_fleet_api.tesla.vehicle.commands.Commands legacy_import_same_class=True signed_transport_envelope_bytes=52021001 decoded_command=RKE_ACTION_LOCK result=published protobuf package works at Home Assistant's exact protobuf pin

protobuf_runtime=6.32.0
tesla_protocol=0.5.0
commands_imported=tesla_fleet_api.tesla.vehicle.commands.Commands
legacy_import_same_class=True
signed_transport_envelope_bytes=52021001
decoded_command=RKE_ACTION_LOCK
result=published protobuf package works at Home Assistant's exact protobuf pin

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

🔧 **Review** - 1 issue found → auto-fixed ✅

• 🚨 docs/bluetooth_vehicles.md:538 - The required criterion says “No public API change,” but this hunk replaces a previously documented consumer import while the entire tesla_fleet_api.tesla.vehicle.proto package is deleted. Existing code using from tesla_fleet_api.tesla.vehicle.proto... will now fail with ModuleNotFoundError. Confirm that this breaking change is acceptable, or retain compatibility alias modules that re-export tesla_protocol.command without vendoring definitions.

🔧 Fix: Restore legacy protobuf import compatibility
✅ Re-checked - no issues remain.

✅ **Test** - passed

✅ No issues found.

• git diff --stat/--name-status cc5dd02c599e31e1bddf1ff8343a46c570121476..c8470db40706f7b2da392ac246f33e28e8444ab8
• rg -n "tesla_fleet_api\.tesla\.vehicle\.proto|from \.proto|vehicle\.proto" tesla_fleet_api tests scripts pyproject.toml
• uv run pytest tests/test_proto_compatibility.py tests/test_ble_mocked_commands.py tests/test_cross_transport_parity.py
• uv run pytest
• Consumer round-trip using tesla_protocol.command.vcsec_pb2 and the legacy compatibility import
• uv run --with protobuf==6.32.0 python ... to construct, serialize, and decode an RKE lock command envelope
• git status --short after removing generated pytest and Python caches

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.