fix(proto): pin protobuf gencode to 6.32.0 for Home Assistant compatibility

[Bre77]

Intent

Make tesla-fleet-api importable under protobuf 6.32.0 so it can drop into Home Assistant core (which pins protobuf==6.32.0) without forcing a core-wide protobuf bump, then cut patch release 1.5.2. The 1.5.1 protobuf gencode under tesla_fleet_api/tesla/vehicle/proto/ was stamped 6.33.4 and calls ValidateProtobufRuntimeVersion(6,33,4,...), which protobuf refuses to load on a 6.32.0 runtime (gencode newer than runtime => VersionError). Decisions made: (1) Regenerated all nine *_pb2.py from the UNCHANGED .proto sources using the standalone protoc v32.0 toolchain via the repo's canonical tools/regenerate_protos.sh (protoc-32.0 on PATH); under unified protobuf versioning protoc vX.Y stamps Python gencode 6.X.Y, so v32.0 yields 6.32.0. This is deliberately a toolchain/version-only change: only the version-stamp lines change and the serialized descriptors are byte-identical (no schema drift). Generated files were regenerated, NOT hand-edited (AGENTS.md forbids editing them). The .proto sources are intentionally untouched. (2) Raised the pyproject protobuf floor from >=6.31.1 to >=6.32.0. This is a correctness fix, not preference: I empirically verified gencode 6.32.0 fails to import under runtime 6.31.1 (VersionError) but succeeds under 6.32.0, so the old floor was unsafe. The floor is intentionally not raised ABOVE 6.32.0 so Home Assistant's exact 6.32.0 pin still satisfies it. No upper cap was added on purpose: protobuf 7.x loads major-6 gencode without error, so a <7 cap would only exclude valid runtimes. (3) Bumped version 1.5.1 -> 1.5.2 in pyproject.toml, tesla_fleet_api/init.py, and the tracked egg-info; deliberately did NOT create/push a git tag or publish (the release tag is pushed after merge by the maintainer). (4) Documented the reproducible regen (protoc v32.0 -> 6.32.0 gencode) and the floor-must-match-gencode rule in AGENTS.md. Verified: with protobuf==6.32.0 all nine _pb2 modules import cleanly and the full test suite passes (37 passed); suite also green under the lockfile's resolved protobuf. The uv.lock and egg-info updates are regenerated artifacts consistent with these changes. Note: pre-existing ruff-format warnings on unrelated tessie/ files exist on base HEAD and are not part of this change.

What Changed

• Regenerated all nine tesla/vehicle/proto/*_pb2.py modules with the protoc v32.0 toolchain so the ValidateProtobufRuntimeVersion stamp is 6.32.0 instead of 6.33.4, letting the package import under Home Assistant's pinned protobuf==6.32.0 (the .proto sources are untouched, so only the version-stamp lines change — serialized descriptors are byte-identical).
• Raised the protobuf floor in pyproject.toml from >=6.31.1 to >=6.32.0 to match the stamped gencode (verified: gencode 6.32.0 fails to import under runtime 6.31.1 and loads cleanly under 6.32.0 and 7.x), and bumped the package version 1.5.1→1.5.2 across pyproject.toml, __init__.py, and egg-info, with uv.lock regenerated to match.
• Documented the protoc-v32.0 → 6.32.0 gencode regen and the floor-must-match-gencode rule in AGENTS.md/tools/regenerate_protos.sh, and bumped upgradeProtoc.sh PROTOC_VERSION to 32.0 for consistency.

Risk Assessment

✅ Low: A toolchain/version-only change: proto diffs are verified to be pure version-stamp edits with byte-identical descriptors, the protobuf floor correctly matches the stamped gencode, and the version bump is consistent across all tracked files.

Testing

Confirmed the diff makes only the intended toolchain/version changes (9 gencode files re-stamped 6.33.4→6.32.0, floor →>=6.32.0, version →1.5.2). The decisive check was an end-to-end import matrix: installing the built package into a clean venv and forcing each protobuf runtime showed all nine pb2 modules and the top-level package import cleanly under protobuf 6.32.0 (Home Assistant's exact pin) and under 7.34.1, while 6.31.1 raises VersionError — exactly proving the HA-compatibility goal and that the raised floor is a correctness fix with no unnecessary upper cap. The full pytest suite passes (37 passed). This is a library/tooling change with no UI surface, so no visual artifact applies; evidence is the CLI import-matrix transcript.

Evidence: protobuf runtime import-compatibility matrix

protobuf==6.32.0 (HA pin): gencode import OK (9/9), import tesla_fleet_api OK v1.5.2 protobuf==6.31.1 (old floor): VersionError on all 9 (gencode 6.32.0 > runtime 6.31.1) protobuf==7.34.1: gencode import OK (9/9), import tesla_fleet_api OK v1.5.2

tesla-fleet-api 1.5.2 — protobuf runtime compatibility matrix
Installed the built package into a fresh Python 3.14 venv, then forced each
protobuf runtime and imported all nine *_pb2 gencode modules + top-level package.

==================== protobuf==6.32.0 (Home Assistant's exact pin) ====================
installed runtime protobuf: 6.32.0
gencode import OK (9/9): car_server common errors keys managed_charging signatures universal_message vcsec vehicle
top-level import tesla_fleet_api OK, __version__ = 1.5.2

==================== protobuf==6.31.1 (the OLD floor, now excluded) ====================
installed runtime protobuf: 6.31.1
gencode import OK (0/9)
  FAIL (all 9) -> VersionError | Detected incompatible Protobuf Gencode/Runtime versions:
                  gencode 6.32.0 runtime 6.31.1.
  top-level FAIL: VersionError
  => proves raising the floor to >=6.32.0 is a correctness fix, not preference.

==================== protobuf==7.34.1 (lockfile-resolved, no upper cap) ====================
installed runtime protobuf: 7.34.1
gencode import OK (9/9): car_server common errors keys managed_charging signatures universal_message vcsec vehicle
top-level import tesla_fleet_api OK, __version__ = 1.5.2
  => major-6 gencode loads fine on 7.x; a <7 cap would only exclude valid runtimes.

Gencode stamp change (all 9 files, version-stamp lines only, descriptors byte-identical):
  # Protobuf Python Version: 6.33.4  ->  6.32.0
  ValidateProtobufRuntimeVersion(PUBLIC, 6, 33, 4, ...)  ->  (PUBLIC, 6, 32, 0, ...)

pyproject.toml floor: protobuf>=6.31.1 -> protobuf>=6.32.0
version: 1.5.1 -> 1.5.2 (pyproject.toml, tesla_fleet_api/__init__.py, egg-info)
Test suite: uv run pytest tests -> 37 passed, 8 subtests passed

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

✅ **Review** - passed

✅ No issues found.

✅ **Test** - passed

✅ No issues found.

• Inspected diff: 9 *_pb2.py files changed 6.33.4→6.32.0 stamp only; pyproject.toml floor 6.31.1→6.32.0; version 1.5.1→1.5.2 across pyproject/init/egg-info
• End-to-end import matrix — installed the built package into a fresh uv Python 3.14 venv and forced each runtime: protobuf==6.32.0 → all 9 gencode modules + import tesla_fleet_api (v1.5.2) OK; protobuf==6.31.1 → VersionError on all 9 (confirms old floor was unsafe); protobuf==7.34.1 → all 9 OK (confirms no upper cap needed)
• uv run pytest tests → 37 passed, 8 subtests passed
• Confirmed working tree clean after removing transient build/ artifact from package install

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

• ⚠️ upgradeProtoc.sh:1 - upgradeProtoc.sh hardcodes PROTOC_VERSION=31.1, which installs a protoc that stamps gencode 6.31.1 — below the new 6.32.0 floor and inconsistent with the shipped gencode and the documented Home Assistant compatibility requirement (protoc v32.0). Left unfixed because it is an executable variable, not a doc comment, and needs a human call on whether this legacy root-level script is still canonical alongside tools/regenerate_protos.sh.

🔧 Fix: Bump upgradeProtoc.sh PROTOC_VERSION to 32.0 for gencode pin
✅ Re-checked - no issues remain.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.