feat: Node::export_channel_attestation (RFC staging)

[rsafier]

Status: review-staging draft on the rsafier fork. See rsafier/rust-lightning#1 for the one-accessor PR this depends on.

Summary

Adds a new public read-only API on `Node`:

```rust
pub fn export_channel_attestation(
&self, channel_id: &ChannelId,
) -> Result<attestation::ChannelAttestation, Error>;

pub fn list_channel_attestations(&self) -> Vecattestation::ChannelAttestation;
```

Returns, for the current state of each channel:

• Unsigned holder commitment transaction (what we'd broadcast on force-close)
• Counterparty's ECDSA signature over it (BIP-143, SIGHASH_ALL)
• Both funding pubkeys, distinguishably (`holder_funding_pubkey`, `counterparty_funding_pubkey`)
• Balances, pending HTLCs, capacity, `is_outbound`

No secret material exposed. The counterparty's signature is cryptographically attributable to them regardless of who holds it.

Implementation (new module `src/attestation.rs`, ~180 LOC)

1. `ChainMonitor::get_monitor` → `LockedChannelMonitor` (existing public API).
2. New in paired rust-lightning PR: `ChannelMonitor::channel_keys_id()`.
3. `SignerProvider::derive_channel_signer(channel_keys_id)` (existing trait method) → `signer.pubkeys(&secp).funding_pubkey` = holder pubkey.
4. `ChannelMonitor::unsafe_get_latest_holder_commitment_txn` (existing, `unsafe_revoked_tx_signing` feature enabled on our lightning dep) → signed holder commit tx.
5. Parse funding-input witness `[empty, sig_A, sig_B, 2-of-2 redeem script]` to pull both pubkeys + sigs.
6. Match the holder pubkey to one of them → know which sig is the counterparty's.
7. Strip witness → unsigned commit tx.

Proof

Regtest end-to-end in the lightning-attestor harness: two `ldk-server` nodes built from this branch, six channel scenarios (initial / outbound-pay / bidirectional / htlc-inflight / htlc-settled / multi-channel). Each snapshot's extracted bundle passes an independent BIP-143 counterparty-sig verification against the counterparty's funding pubkey.

Non-goals

• Revocation secrets, history beyond current unrevoked state — neither is available from LDK (by design, it's what makes Lightning safe) and we don't ask for them.
• `commitment_number` returned as `0` for now; can be de-obscured from locktime+sequence using both parties' `payment_basepoint` if needed, but the cryptographic BIP-143 verification doesn't depend on it.

Ask

Feedback on the method signature, the module placement, and whether `ChannelAttestation` should live in `ldk-node` or move up into rust-lightning (we went with ldk-node since the witness-parsing + signer-rederivation is LDK-node-level plumbing, not a rust-lightning primitive).