design(spsc): decide whether to expose a dedicated queue

Parent: #206

## Goal

Determine whether a distinct public SPSC queue provides enough static API value or measured implementation benefit to justify a dedicated module.

## Questions

- Is a non-cloneable sender and receiver contract materially easier to use correctly than MPSC with one sender?
- Can a specialized backend improve latency, allocation, or synchronization without creating disproportionate maintenance cost?
- Should SPSC initially be a nominal wrapper over the single-consumer core or wait for a specialized backend?

## Acceptance criteria

- Compare the proposed API and implementation with using MPSC directly.
- Benchmark bounded and unbounded SPSC against the MPSC one-producer path and relevant ecosystem channels.
- Record an explicit implement-or-defer decision. If implemented, preserve non-cloneable endpoints and exclusive `&mut self` operations without exposing backend markers.

Depends on #208 and #209.

Start with parent issue #206 and dependencies #208 and #209. Compare the proposed SPSC API and implementation with direct MPSC use, then benchmark bounded and unbounded SPSC against the MPSC one-producer path and relevant ecosystem channels. Done means recording an explicit implement-or-defer decision and, if implemented, preserving the stated endpoint and operation constraints.

Written by the indexing model from the issue text.