Backpressure policy roadmap: shedding variants, watermarks, limiter placement

[cognis-digital]

safequeue supports three backpressure policies when a bounded-capacity queue is full (see docs/ARCHITECTURE.md):

• PolicyReject (default) — fail fast with ErrBackpressure (HTTP 429). Producer slows down / retries.
• PolicyDropOldest — dead-letter the oldest ready message to admit the new one (leased messages are never dropped).
• PolicyBlock — EnqueueWait(ctx, ...) blocks until room or the context is canceled.

I'd like input on where to take this next.

1. Load-shedding variants.
DropOldest favors fresh work (good for live telemetry). Should we add:

• DropNewest (reject the incoming, keep the backlog — good for "process in order, don't lose the queue we have")?
• Priority-aware shedding — drop the lowest-priority ready message rather than strictly the oldest?

2. High/low watermarks instead of a hard cap.
A single Capacity is a hard wall. A common pattern is hysteresis: start shedding/throttling at a high watermark and stop only once depth falls back below a low watermark, to avoid thrashing at the boundary. Depth() already exposes current + high-water. Is watermark-based admission worth adding?

3. Where should the rate limiter sit relative to backpressure?
Right now ratelimit is a separate package the caller composes in front of Enqueue. Should the queue optionally own an admission limiter (config-wired, per-fairness-key), or is keeping them decoupled the better design? Decoupled is more flexible; integrated is more turnkey.

4. Backpressure signaling to producers.
Beyond 429, would a Retry-After header (derived from the limiter's Reserve().Delay() or from drain rate) be useful for HTTP clients?

What backpressure behavior do your workloads actually need — fail-fast, block, or shed — and at what depth?