command: define NavigationSuperchargerRequest.id (supercharger location)

[Bre77]

Intent

• CarServer.NavigationSuperchargerRequest had tag 1 reserved and unmodelled, so the message could only ever carry a trip order with no supercharger named. This defines tag 1 as int64 id, the supercharger location the request navigates to.
  • Tag, wire type and semantics, from four independent lines that agree:
    • Schema evidence for this message types tag 1 as int64 (varint) with the trip-order enum at tag 2 - the same evidence that drove the tag-2 correction in fix: correct NavigationSuperchargerRequest wire-format tag (BREAKING) #32.
    • Tesla's navigation_sc_request Fleet API surface takes exactly two parameters, id and order. order is tag 2, which leaves id as the tag 1 value.
    • CarServer.Superchargers.id - the identifier a GetNearbyChargingSites reply returns for each site, and the only supercharger identifier in this package - is likewise an int64 at tag 1.
    • A live send with tag 1 absent was accepted (result: true) against a vehicle on an active route, and the route was never recalculated: destination and ETA unchanged, no preconditioning. Consistent with the vehicle being asked to add a charging stop that the request never identifies.
  • Named id to match Superchargers.id and the Fleet API parameter; RemoveChargeScheduleAction.id sets the same in-repo precedent.
  • Wire-compatible addition, so minor per .changeset/README.md: nothing is renamed or renumbered, and "order" stays reserved by name so the misdeclared identifier can't come back. Un-reserving the number trips RESERVED_MESSAGE_NO_DELETE, which buf.yaml already excepts repo-wide.
• Adds fixtures/golden/navigation_supercharger_id.json (synthetic ids, id alone and paired with each trip order) with matching TypeScript and Python round-trip tests.
• Full CI gate sequence is green locally: buf lint, buf breaking against main, upstream_coverage.py --mode pinned, check_reply_coverage.py, catalog rebuild and tests, both language suites, and pnpm run generate leaving a clean tree.

Flagged, not changed here

• remote_nav_trip_order at tag 2 is independently correct, not a knock-on of the tag 1 misreading: the same evidence places an order-typed field at tag 2 in this message specifically, and the identical enum type appears at its own distinct tag in each sibling nav message. Nothing to revisit.
• The enum's value numbering is a separate open question. All four nav messages here number RemoteNavTripOrder as UNKNOWN=0, REPLACE=1, PREPEND=2, APPEND=3, but the evidence for the app-side enum has no UNKNOWN and numbers it Replace=0, Prepend=1, Append=2 - one lower throughout. If that holds, every order value this library emits selects the wrong mode. It predates this change, spans four published messages, and would be a breaking fix, so it needs its own decision.
• Encoding id in the api command handler is a separate change, blocked on this release.