Clarify when the pairing round count resets

README.md

@@ -984,7 +984,7 @@ A failed key confirmation results in [`pair/abort`](#client--server-pairabort) w
 
 An attempt runs **rounds** against the same pairing code. A round begins with [`server/pair-init`](#server--client-serverpair-init) and ends with the client's verification of `server_kc` from [`server/pair-confirm`](#server--client-serverpair-confirm), or with the attempt. Within it the client emits the code, the operator enters it, and a separate CPace run - fresh scalars, its own `sid` - follows. On a verified `server_kc` the client continues with [`client/pair-confirm`](#client--server-clientpair-confirm). On failure the client either sends [`client/pair-retry`](#client--server-clientpair-retry), asking for another round, or ends the attempt with [`pair/abort`](#client--server-pairabort) reason `pairing_code_mismatch`. The client SHOULD retry, and MUST abort instead at the round limit. A retry keeps the attempt, its pairing code, and its running [attempt timeout](#entering-and-leaving-pairing) in place; the server begins the next round with a new `server/pair-init`.
 
-After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action, which also resets the count. The count is not partitioned by `server_id` or source address. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit.
+After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit. Only a verified `server_kc` and an operator action that releases held-back attempts reset the count: the end of a cooldown or an operator action during an attempt does not. The count is not partitioned by `server_id` or source address.
 
 The limit is not an error state - the method stays offered - and while it holds an attempt back the client sends [`client/pair-pending`](#client--server-clientpair-pending), optionally saying in `message` what it waits for.
 

pairing.md

@@ -182,7 +182,7 @@ A failed key confirmation results in [`pair/abort`](#client--server-pairabort) w
 
 An attempt runs **rounds** against the same pairing code. A round begins with [`server/pair-init`](#server--client-serverpair-init) and ends with the client's verification of `server_kc` from [`server/pair-confirm`](#server--client-serverpair-confirm), or with the attempt. Within it the client emits the code, the operator enters it, and a separate CPace run - fresh scalars, its own `sid` - follows. On a verified `server_kc` the client continues with [`client/pair-confirm`](#client--server-clientpair-confirm). On failure the client either sends [`client/pair-retry`](#client--server-clientpair-retry), asking for another round, or ends the attempt with [`pair/abort`](#client--server-pairabort) reason `pairing_code_mismatch`. The client SHOULD retry, and MUST abort instead at the round limit. A retry keeps the attempt, its pairing code, and its running [attempt timeout](#entering-and-leaving-pairing) in place; the server begins the next round with a new `server/pair-init`.
 
-After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action, which also resets the count. The count is not partitioned by `server_id` or source address. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit.
+After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit. Only a verified `server_kc` and an operator action that releases held-back attempts reset the count: the end of a cooldown or an operator action during an attempt does not. The count is not partitioned by `server_id` or source address.
 
 The limit is not an error state - the method stays offered - and while it holds an attempt back the client sends [`client/pair-pending`](#client--server-clientpair-pending), optionally saying in `message` what it waits for.