LocalChain::insert_block misreports PrevBlockhashMismatch as a genesis AlterCheckPointError #2357

Describe the bug

LocalChain::insert_block maps any apply_changeset failure to a hard-coded genesis AlterCheckPointError:

// crates/chain/src/local_chain.rs
self.apply_changeset(&changeset)
    .map_err(|_| AlterCheckPointError {
        height: 0,
        original_hash: self.genesis_hash(),
        update_hash: changeset
            .blocks
            .get(&0)
            .cloned()
            .flatten()
            .map(|d| d.to_blockhash()),
    })?;

When inserting a contiguous Header whose prev_blockhash does not link (real error: ApplyBlockError::PrevBlockhashMismatch):

• height is always 0
• original_hash is always the genesis hash
• update_hash is usually None (changeset only contains the inserted height, not height 0)
• Display therefore says "failed to remove block at height 0", which is wrong

Same-height hash conflicts are handled correctly earlier in insert_block. Only the apply_changeset error path is broken. This is distinct from #2309 (apply_changeset silently replacing genesis).

To Reproduce

Ignored unit test in-tree:

cargo test -p bdk_chain --test test_local_chain \
  insert_block_prev_blockhash_mismatch_error_is_not_genesis -- --ignored --nocapture

Minimal sketch:

fn header(prev_blockhash: BlockHash) -> Header { /* ... */ }

let genesis = header(hash!("_"));
let mut chain = LocalChain::from_blocks([(0, genesis)].into()).unwrap();
let err = chain
    .insert_block(1, header(hash!("not_genesis")))
    .unwrap_err();

// Current: AlterCheckPointError { height: 0, original_hash: genesis, update_hash: None }
// Display: "failed to remove block at height 0: original=..."
assert_ne!(err.height, 0); // fails today

Expected behavior

Error metadata should identify the failing height/hash (or preserve ApplyBlockError), not claim a genesis removal. Callers must be able to distinguish a mid-chain prev_blockhash clash from a genesis problem.

Build environment

• BDK tag/commit: master
• Crate: bdk_chain
• Rust/Cargo version: MSRV 1.85.0+

Which backend(s) are relevant (if any)?

• None / not backend-related (e.g. bdk_chain, bdk_core)

Is this blocking production use?

• Yes
• No

Additional context

Suggested fix: map ApplyBlockError into a correct AlterCheckPointError (or change the return type to expose ApplyBlockError / a unified error). Happy-path behavior need not change.

Related: #2309.