Clarify splice_locked retransmission on reconnect

When we reconnect, we send `splice_locked` for the latest splice that
reached acceptable depth. To avoid sending `splice_locked` at every
reconnection, we omit it if the `commitment_number` has progressed since
the last time we sent `splice_locked`, which implicitly means that our
peer received our `splice_locked` since they stored more recent updates
to the channel.

02-peer-protocol.md

@@ -3056,16 +3056,20 @@ A receiving node:
         - MUST send its `tx_signatures` for that funding transaction.
       - if it has already received `tx_signatures` for that funding transaction:
         - MUST send its `tx_signatures` for that funding transaction.
-    - if `next_funding_txid` matches the latest funding transaction:
-      - if that transaction has reached acceptable depth:
-        - MUST send `splice_locked`.        
     - if it also sets `next_funding_txid` in its own `channel_reestablish`, but the
       values don't match:
       - MUST send an `error` and fail the channel.
     - otherwise:
       - MUST send `tx_abort` to let the sending node know that they can forget
         this funding transaction.
 
+A receiving node:
+  - MUST send `splice_locked` for the most recent splice transaction that reached
+    acceptable depth, unless `splice_locked` was already sent for this transaction
+    and `next_commitment_number` is strictly greater than the `commitment_number + 1`
+    that was used when `splice_locked` was previously sent (which indicates that
+    the previous `splice_locked` was received).
+
 A node:
   - MUST NOT assume that previously-transmitted messages were lost,
     - if it has sent a previous `commitment_signed` message: