docs: 为006绑定回执增加ICCID

docs/architecture/03-binding-flow.md

@@ -54,22 +54,7 @@ sequenceDiagram
 
 ## Binding Response (V2.0)
 
-The current V2.0 protocol defines the successful `msg_id=006` response as:
-
-```json
-{
-  "msg_id": "006",
-  "status": "success",
-  "data": {
-    "uuid": "53D22B6DA20001"
-  }
-}
-```
-
-The V2.0 response does not define an `iccid` field. Adding ICCID to the
-binding receipt is therefore a protocol extension that requires coordinated
-firmware and backend changes. A compatible proposal is to add it under
-`data`, while preserving the existing `status` and `data.uuid` fields:
+The V2.0 protocol defines the successful `msg_id=006` response as:
 
 ```json
 {
@@ -83,9 +68,11 @@ firmware and backend changes. A compatible proposal is to add it under
 ```
 
 The ICCID must come from the authoritative IMEI-to-ICCID provisioning record
-or a validated device report; it must not be derived from the IMEI. This
-proposed field is not part of the current V2.0 contract until both sides
-accept and implement the extension.
+The `iccid` field is now part of the documented `006` success receipt. It must
+come from the authoritative IMEI-to-ICCID provisioning record or a validated
+device report; it must not be derived from the IMEI. Firmware and backend
+runtime support still need to be deployed together before this field can be
+relied on in production.
 
 ## Related Tables