Merge bitcoindevkit/bdk#2299: refactor(chain)!: remove `Anchor::confirmation_height_u...

Merge bitcoindevkit/bdk#2299: refactor(chain)!: remove `Anchor::confirmation_height_upper_bound`

74de3a0d656448e6851771952e90b060e890b260 refactor(chain)!: remove `Anchor::confirmation_height` (志宇)
e6a63e450b8e8e56c9daeb3e2341a88b9f90a26e docs(chain): note false-pending in CanonicalView::balance (志宇)
dadeb37fd94ca7ded7adee2d2bf69047135f6d23 refactor(chain)!: rename Anchor::confirmation_height_upper_bound (志宇)
306e052be996ed8ed62ce3e6613dadffe8e04235 docs(chain): state that an anchor names the confirming block (志宇)

Pull request description:

  ### Description

  Fixes #2298.

  The `Anchor` trait said an anchor block *might* be a descendant of the confirming block. Nothing produces such anchors: Electrum validates a merkle proof, Esplora uses the confirming block from `TxStatus`, and `TxPosInBlock` carries the tx index inside that block.

  So an anchor's height is exact. This PR drops that framing from the `Anchor` docs and removes `Anchor::confirmation_height_upper_bound`. Callers use `anchor_block().height` directly. Every implementation already returned that, so there is no behaviour change.

  `ChainPosition::confirmation_height_upper_bound` and `confirmations_lower_bound` are kept. A transitively confirmed tx (`ChainPosition::Confirmed { transitively: Some(_), .. }`) carries a descendant's anchor, so for it the height really is an upper bound. Their docs, along with those of `CanonicalTxOut::is_mature` / `is_confirmed_and_spendable` and `CanonicalView::balance`, now attribute the bound to transitive confirmation. `transitively_confirmed_tx_reports_descendant_anchor_height` covers this case.

  ### Changelog notice

  **`bdk_chain`**

  - Removed `Anchor::confirmation_height_upper_bound`. An anchor names the confirming block, so use `anchor_block().height`.
  - Updated `Anchor` docs: an anchor block is no longer described as possibly a descendant of the confirming block.
  - Updated `ChainPosition::confirmation_height_upper_bound` and `confirmations_lower_bound` docs: the values are exact unless the position is confirmed transitively.
  - Updated `CanonicalView::balance` docs: a transitively confirmed output may be counted as pending by a confirmation-depth `is_settled`.

  ### Checklists

  #### All Submissions:
  * [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk/blob/master/CONTRIBUTING.md)

  #### Bugfixes:
  * [x] This pull request breaks the existing API
  * [x] I'm linking the issue being fixed by this PR

  🤖 Generated with [Claude Code](https://claude.com/claude-code)

ACKs for top commit:
  evanlinjin:
    self-ACK 74de3a0d656448e6851771952e90b060e890b260

Tree-SHA512: e1623c08e04da24fe2abfbfa8fd80ecef01bab1e242a0a208eb89134862e9524f7458c3f645ad1218848352dadf06578426a273d5030be5c00f2e950b488fd6a