Please address the comments from this code review:

## Overall Comments
- The new `UnconfirmedMessageHandlerImpl` docstring says it uses exponential backoff, but `calculateNextInterval` implements linear backoff (`(retry+1)*baseInterval`); consider either updating the comment or changing the logic to match the intended strategy.
- In `TestOnACKCallback`, `ackedResources` is appended to from multiple callback goroutines without synchronization, which is a data race under the race detector; consider guarding it with a mutex or using a channel to collect results.

## Individual Comments

### Comment 1
<location path="pkg/retry/handler/unconfirmed_message_handler.go" line_range="27-29" />
<code_context>
+// Each resource has independent retry state with exponential backoff.
</code_context>
<issue_to_address>
**suggestion:** Backoff description says exponential but implementation is linear; align naming/behavior.

This comment promises exponential backoff, but the implementation uses linear backoff (`(retry + 1) * baseInterval`), matching the previous behavior. Please either change the wording to “linear backoff” or implement true exponential backoff (e.g., `baseInterval * (1 << retry)` with appropriate caps) to avoid confusing future readers.

```suggestion
 // UnconfirmedMessageHandlerImpl handles ACK/NACK messages for multiple resources.
 // Each resource has independent retry state with linear backoff.
 type UnconfirmedMessageHandlerImpl struct {
```
</issue_to_address>

### Comment 2
<location path="pkg/retry/handler/unconfirmed_message_handler.go" line_range="203-217" />
<code_context>
+	// Schedule next retry
+	h.resetTimer(resourceID, state, nextInterval)
+
+	// Signal retry (non-blocking); if the channel is full we log and drop the signal.
+	select {
+	case <-h.ctx.Done():
+		return
+	case h.retryCommandCh <- resourceID:
+	default:
+		// If the channel is full or the consumer goroutine is busy, we assume that currently a
+		// transimssion of a message is in progress. This means, that we do not need to enqueue
+		// another message immediately afterwards. Thus, we drop the retry signal and log a warning.
</code_context>
<issue_to_address>
**suggestion:** Clarify behavior of the unbuffered retry channel and the "full" terminology.

Because `retryCommandCh` is unbuffered, "channel full" isn't quite accurate here: the `default` branch is taken when there is no receiver ready at the instant of the send, not due to queued signals. If this drop-when-no-receiver behavior is what you want, consider wording it in terms of "no receiver ready". If you instead want to allow a small backlog of retries, a buffered channel would more directly express that intent than a non-blocking send on an unbuffered channel.

```suggestion
	// Schedule next retry
	h.resetTimer(resourceID, state, nextInterval)

	// Signal retry (non-blocking); if no receiver is ready on the unbuffered channel, we drop the signal.
	select {
	case <-h.ctx.Done():
		return
	case h.retryCommandCh <- resourceID:
	default:
		// If no receiver is ready or the consumer goroutine is busy, we assume that a transmission
		// of a message is currently in progress. This means we do not need to enqueue another retry
		// signal immediately afterwards. Thus, we drop the retry signal and log a warning.
		log.Warnf("[%s] No receiver ready on retry channel, dropping retry signal for %s", h.handlerName, resourceID)
	}
}
```
</issue_to_address>

### Comment 3
<location path="pkg/retry/handler/unconfirmed_message_handler.go" line_range="157-166" />
<code_context>
+	// HandleNACK is currently a no-op and has the same behavior as not reciving any [N]ACK message.
</code_context>
<issue_to_address>
**nitpick (typo):** Fix small typos in comments to improve readability.

Please fix the typos: "reciving" → "receiving" and "transimssion" → "transmission".

Suggested implementation:

```golang
	// HandleNACK is currently a no-op and has the same behavior as not receiving any [N]ACK message.

```

```golang
transmission

```
</issue_to_address>

### Comment 4
<location path="pkg/retry/handler/unconfirmed_message_handler.go" line_range="42" />
<code_context>
+	onACK func(resourceID string)
+	ctx   context.Context
+
+	// cleanupDone signals when cleanup is complete
+	cleanupDone concurrency.Stopper
 }
</code_context>
<issue_to_address>
**issue (complexity):** Consider simplifying the handler’s lifecycle and retry signaling by removing the Stopper abstraction and making the retry channel’s coalescing behavior explicit.

You can trim a fair bit of complexity without losing any of the new functionality:

### 1. Avoid `concurrency.Stopper` if `Stopped()` isn’t needed

If nothing outside this package is actually calling `Stopped()`, you can drop the `Stopper` in favor of the existing `ctx` + channel close. That removes a whole lifecycle abstraction:

```go
type UnconfirmedMessageHandlerImpl struct {
    handlerName    string
    baseInterval   time.Duration
    resources      map[string]*resourceState
    mu             sync.Mutex
    retryCommandCh chan string
    onACK          func(resourceID string)
    ctx            context.Context
}

// NewUnconfirmedMessageHandler creates a new handler for per-resource ACK/NACK tracking.
// It can be stopped by canceling the context.
func NewUnconfirmedMessageHandler(ctx context.Context, handlerName string, baseInterval time.Duration) *UnconfirmedMessageHandlerImpl {
    h := &UnconfirmedMessageHandlerImpl{
        handlerName:    handlerName,
        baseInterval:   baseInterval,
        resources:      make(map[string]*resourceState),
        retryCommandCh: make(chan string),
        ctx:            ctx,
    }

    go func() {
        <-ctx.Done()
        h.mu.Lock()
        defer h.mu.Unlock()
        for _, state := range h.resources {
            if state.timer != nil {
                state.timer.Stop()
            }
        }
        close(h.retryCommandCh)
    }()

    return h
}
```

If you *do* need to expose a “stopped” signal, you can derive it from the context instead of a separate `Stopper`:

```go
// Stopped exposes the underlying context as a read‑only signal.
func (h *UnconfirmedMessageHandlerImpl) Stopped() <-chan struct{} {
    return h.ctx.Done()
}
```

This keeps lifecycle signaling but removes the extra `Stopper`/`ReadOnlyErrorSignal` layering.

### 2. Make the retry channel semantics explicit

Right now the non‑blocking send on an unbuffered channel is subtle and the log message (“channel full”) is misleading. If the intent is “at most one pending retry, and drop additional ones while the consumer is busy”, you can make that policy explicit with a small buffer and coalescing flag:

```go
type resourceState struct {
    retry              int32
    numUnackedSendings int32
    timer              *time.Timer
    retryPending       bool // new: whether a retry signal is already pending
}
```

```go
func NewUnconfirmedMessageHandler(ctx context.Context, handlerName string, baseInterval time.Duration) *UnconfirmedMessageHandlerImpl {
    h := &UnconfirmedMessageHandlerImpl{
        handlerName:    handlerName,
        baseInterval:   baseInterval,
        resources:      make(map[string]*resourceState),
        retryCommandCh: make(chan string, 1), // small buffer
        ctx:            ctx,
    }
    // cleanup goroutine as above ...
    return h
}
```

And in `onTimerFired`:

```go
func (h *UnconfirmedMessageHandlerImpl) onTimerFired(resourceID string) {
    h.mu.Lock()
    defer h.mu.Unlock()

    if h.ctx.Err() != nil {
        return
    }

    state, exists := h.resources[resourceID]
    if !exists || state.numUnackedSendings == 0 {
        return
    }

    state.retry++
    nextInterval := h.calculateNextInterval(state.retry)

    log.Infof("[%s] Resource %s has %d unacked messages, suggesting retry %d (next in %s)",
        h.handlerName, resourceID, state.numUnackedSendings, state.retry, nextInterval)

    h.resetTimer(resourceID, state, nextInterval)

    // Coalesce retry signals: only enqueue if none is pending.
    if !state.retryPending {
        select {
        case <-h.ctx.Done():
            return
        case h.retryCommandCh <- resourceID:
            state.retryPending = true
        default:
            // buffer full: keep retryPending true, don't log "full" since this is expected coalescing
        }
    }
}
```

Then clear `retryPending` when the consumer actually processes the retry (where you receive from `RetryCommand()`):

```go
// in the consumer, after handling a retry for resourceID:
handler.ClearRetryPending(resourceID)
```

with a simple method:

```go
func (h *UnconfirmedMessageHandlerImpl) ClearRetryPending(resourceID string) {
    h.mu.Lock()
    defer h.mu.Unlock()
    if state, ok := h.resources[resourceID]; ok {
        state.retryPending = false
    }
}
```

This preserves the “don’t enqueue infinite retries while one is in flight” behavior, but makes the intent obvious and removes the misleading “channel full” warning.
</issue_to_address>