feat: add explicit Exn type erasure

[tisonkun]

Depends on

• refactor!: relax Exn root marker bounds #60, which allows Exn<E> and its marker-only adapters to accept an unsized root marker

Complete workflow

This PR makes type erasure useful specifically at boundaries that require one concrete callback error type while callback implementations retain their own typed errors:

use exn::ErasedExn;
use exn::Exn;
use exn::ResultExt;

fn storage_callback() -> Result<(), ErasedExn> {
    read_storage()             // exn::Result<_, StorageError>
        .map_err(Exn::erase)?; // erase only at the callback boundary
    Ok(())
}

fn run_callback(
    callback: impl FnOnce() -> Result<(), ErasedExn>,
) -> exn::Result<(), CallbackFailed> {
    callback().or_raise(|| CallbackFailed) // typed again above the boundary
}

The intended flow is therefore:

1. keep concrete Exn<E> errors inside each module
2. explicitly erase the root marker where a callback or delegate signature must unify unrelated error types
3. immediately add a typed parent when the host incorporates that callback failure into its own API

The same boundary type also allows heterogeneous callback failures to share a collection and be aggregated with IteratorExt::raise under one typed parent.

API

• add the public alias ErasedExn = Exn<dyn Error + Send + Sync + 'static>
• add Exn::erase(self) -> ErasedExn
• add Deref<Target = dyn Error + Send + Sync> for ErasedExn

ErasedExn gives this common boundary type a standard name without introducing a wrapper or changing its representation. Callers can still define domain-specific aliases such as CallbackExn when that improves their API vocabulary.

erase only changes the compile-time marker. It moves the existing Box<Frame> without allocating, preserves the entire tree, and keeps concrete frame errors available through runtime downcasting.

Deliberate omissions

• no default type parameter for Exn; typed errors remain the default design
• no From<Exn<E>> for ErasedExn because it makes IteratorExt::raise inference ambiguous between identity conversion and erasure
• no std::error::Error wrapper or tree-to-source() policy; interoperability is independent from marker erasure

Open question

• Is erase the right consuming-method name, or should it be into_erased / erased?

Validation

• cargo x lint
• cargo x test --no-capture
• doctest covers the typed → erased callback → typed parent workflow
• integration tests verify allocation reuse, runtime downcasting, callback retyping, and heterogeneous iterator aggregation

[tisonkun]

Temporarily closing and reopening to retrigger the required stack-aware CI checks.