Require to claim revoked local output in its own penalty tx post-anchor

If `option_anchor_outputs` applies, the cheating node can pin spends of its
HTLC-timeout/HTLC-success outputs thanks to SIGHASH_SINGLE malleability.
Using a single penalty transaction for all revoked outputs is thus unsafe as it
could be blocked to propagate long enough for the `_local node's main output_ 's
relative timelock to expire and the cheating party escaping the penalty on this
output.

05-onchain.md

@@ -513,7 +513,14 @@ A local node:
   using the revocation private key.
   - SHOULD extract the payment preimage from the transaction input witness, if
   it's not already known.
-  - MAY use a single transaction to *resolve* all the outputs.
+  - if `option_anchor_outputs` applies:
+  - otherwise:
+    - MAY use a single transaction to *resolve* all the outputs.
+    - if confirmation doesn't happen before reaching `security_delay` blocks from
+  expiry:
+      - MUST *resolve* the _local node's main output_ in its own penalty transaction
+  as if a single resolving-transaction has been previously used its propagation might be
+  under pinning.
   - MUST handle its transactions being invalidated by HTLC transactions.
 
 ## Rationale
@@ -522,10 +529,19 @@ A single transaction that resolves all the outputs will be under the
 standard size limit because of the 483 HTLC-per-party limit (see
 [BOLT #2](02-peer-protocol.md#the-open_channel-message)).
 
-Note: if a single transaction is used, it may be invalidated if the remote node
-refuses to broadcast the HTLC-timeout and HTLC-success transactions in a timely
-manner. Although, the requirement of persistence until all outputs are
-irrevocably resolved, should still protect against this happening. [ FIXME: May have to divide and conquer here, since the remote node may be able to delay the local node long enough to avoid a successful penalty spend? ]
+Note: if `option_anchor_outputs` applies, the cheating node can pin spends of its
+HTLC-timeout/HTLC-success outputs thanks to SIGHASH_SINGLE malleability.
+Using a single penalty transaction for all revoked outputs is thus unsafe as it
+could be blocked to propagate long enough for the `_local node's main output_ 's
+relative locktime to expire and the cheating party escaping the penalty on this
+output. Though this situation doesn't prevent faithful punishment of the second-level
+revoked output if the pinning transaction confirms.
+
+The `security_delay` is a fixed-point relative to the absolute expiration of
+the revoked output at which the punishing node must broadcast a single-spend
+transaction for the revoked output and actively fee-bump it until its confirmation.
+The exact value of `security_delay` is left as a matter of node policy, though we
+recommend 18 blocks (similar to incoming HTLC deadline).
 
 ## Penalty Transactions Weight Calculation