Core API: stringly-typed state, null as the only error, no explicit API mode; not yet library-grade #120

Problem

One of the master plan's locked decisions is "Library-grade docs and API hygiene from now on". The current core API falls short of that in several ways.

• Domain values are strings.
  • TeslaCommands.Charge.chargingState: String? turns the proto oneof into "Charging", "Complete", … (TeslaCommands.kt#L59-L71).`` Those strings are compared in core (BatterySample.isCharging), in the app (`chargingStateText`), in the CSV, in demo data and in tests.
  • TeslaConnection.sessions: List<String> holds enum names, and the UI checks contains("DOMAIN_VEHICLE_SECURITY") (MainScreen.kt#L487, BleTrackingService.kt#L121).``
  • parseActionStatus returns enum.name.
  • A typo or a rename still compiles and then fails silently. Use enums or the generated Wire types instead.
• null is the only error signal.
  • TeslaSession.import/encrypt/decrypt and TeslaCrypto.decryptGcm (where runCatching{…}.getOrNull() swallows every exception) all return null, whether the cause is a wrong VIN, a bad tag, an exhausted counter or a malformed message. All the app can log is "session verification failed".
  • A sealed result type (or typed exceptions) is needed to drive Protocol: replies are routed by trial-decoding; car faults and session resyncs are silently dropped #111 and to show useful errors in the UI.
  • Error handling is also inconsistent: some parsers (TeslaVcsec.parse*, TeslaCommands.parse*) throw on malformed input while TeslaPairing catches, so callers wrap everything in runCatching.
• Explicit API mode is off. Everything in core is public by default: AntiReplayWindow.updateSlidingWindow, TeslaCrypto.randomBytes, the Metadata hash contexts, the BleFramer constants, and so on. Turn on kotlin { explicitApi() } now and decide what is public before the binary-compatibility validator arrives in Phase 3.
• Keying contradicts ADR-0004.
  • ADR-0004 makes the advertised name the identity and the address an attribute, but BleUiState.connections is keyed by address (BleModels.kt#L58-L72),`` while links are keyed by name.
  • UI and notification code join the two through vehicle.address lookups.
  • When an address changes, the old entry stays behind in the state.
• The same helper exists several times. There are two private ByteArray.toHex() copies (TeslaBleController.kt#L1446, SettingsScreen.kt#L355), alongside the stdlib toHexString() that Format BLE names with stdlib toHexString #104 adopted in core. Three test files each define their own String.hex().

Related: #118, #111.