feat(broadcast): add an SPMC specialization

Parent: #206

## Goal

Add the `asyncband::broadcast::spmc` topology when a static single-producer contract provides a clear API or measured implementation benefit over `broadcast::mpmc` used with one sender.

## Current baseline

The unbounded MPMC retention contract is implemented by #117. The bounded MPMC contract remains in #213. An SPMC implementation may be delivered one retention policy at a time; it does not need to wait for the full matrix when the selected policy can be compared with its MPMC counterpart.

## Direction

- Expose one non-cloneable sender with exclusive send methods.
- Keep subscriptions independent and explicitly created.
- Evaluate whether a single-producer sequencer or Disruptor-style bounded ring provides a measured benefit; keep it private either way.
- Keep source under `asyncband/src/broadcast/spmc`; move machinery to `crate::internal` only when it is genuinely shared outside broadcast.

## Acceptance criteria

- Preserve the same public retention contract as the corresponding MPMC variant.
- Compare each specialized path with the matching MPMC broadcast implementation used by one producer.
- Demonstrate that the static sender capability or measured performance benefit justifies a separate public topology.
- Do not retain a separate backend unless its capability or performance benefit justifies the maintenance cost.

The benchmark baseline in #208 is complete. Bounded SPMC work depends on the bounded MPMC contract in #213.

Start with the existing broadcast::mpmc implementation and the benchmark baseline in #208, then review the retention contract from #117 and the bounded dependency in #213. Work under asyncband/src/broadcast/spmc, compare each selected retention policy with the one-producer MPMC path, and consider the public sender capability and measured results done only if they justify a separate topology.

Written by the indexing model from the issue text.