docs(chain): state that an anchor names the confirming block

The `Anchor` trait doc claimed an anchored transaction "could also mean
transaction A is confirmed in a parent block of B". No chain source in
this repo produces such an anchor: electrum only builds one after
`validate_merkle_proof` succeeds, esplora uses `TxStatus`'s confirming
block, and `TxPosInBlock` carries the transaction's index within that
block. The framing only leaves ambiguity for a case that does not occur.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NND8BhEmYTYdLRv4dbUUro

diff --git a/crates/chain/src/tx_data_traits.rs b/crates/chain/src/tx_data_traits.rs
index 7ab8963f4c4f11e59d6c64bb93946173000358e3..d4948b35eeaf16f3f9d9a313fa0b8c0ee2586761 100644 (file)
--- a/crates/chain/src/tx_data_traits.rs
+++ b/crates/chain/src/tx_data_traits.rs
@@ -2,10 +2,8 @@ use crate::{BlockId, ConfirmationBlockTime};
 
 /// Trait that "anchors" blockchain data to a specific block of height and hash.
 ///
-/// If transaction A is anchored in block B, and block B is in the best chain, we can
-/// assume that transaction A is also confirmed in the best chain. This does not necessarily mean
-/// that transaction A is confirmed in block B. It could also mean transaction A is confirmed in a
-/// parent block of B.
+/// If transaction A is anchored in block B, then block B is the block that confirmed transaction
+/// A. If block B is in the best chain, transaction A is confirmed in the best chain.
 ///
 /// Every [`Anchor`] implementation must contain a [`BlockId`] parameter, and must implement
 /// [`Ord`]. When implementing [`Ord`], the anchors' [`BlockId`]s should take precedence