Minor clarificaton on USER_IDENTIFICATION_ASSOCIATION doc.

Test: none
Bug: 150409351
Change-Id: I4c8e11c118a503998736acb37259eb6aaea1c542
diff --git a/automotive/vehicle/2.0/types.hal b/automotive/vehicle/2.0/types.hal
index 733e7dc..2e6fa25 100644
--- a/automotive/vehicle/2.0/types.hal
+++ b/automotive/vehicle/2.0/types.hal
@@ -2847,7 +2847,7 @@
      *
      * Then to associate the user with the custom mechanism, a set request would be made:
      *
-     * int32[0]: 42  // request id
+     * int32[0]: 43  // request id
      * int32[1]: 10  (Android user id)
      * int32[2]: 0   (Android user flags)
      * int32[3]: 1   (number of associations being set)
@@ -2856,7 +2856,7 @@
      *
      * If the request succeeded, the response would be simply:
      *
-     * int32[0]: 42  // request id
+     * int32[0]: 43  // request id
      * int32[1]: 1   (number of associations in the response)
      * int32[2]: 101 (1st type: UserIdentificationAssociationType::CUSTOM_1)
      * int32[3]: 1   (1st value: UserIdentificationAssociationValue::ASSOCIATED_CURRENT_USER)
@@ -2865,7 +2865,7 @@
      * example above, the end state would be 2 associations (FOB and CUSTOM_1). If we wanted to
      * associate the user with just CUSTOM_1 but not FOB, then the request should have been:
      *
-     * int32[0]: 42  // request id
+     * int32[0]: 43  // request id
      * int32[1]: 10  (Android user id)
      * int32[2]: 2   (number of types set)
      * int32[3]: 1   (1st type: UserIdentificationAssociationType::KEY_FOB)