Pre-readiness unsubscribes are retained as tombstones, so the worker-subscription admission map can grow unbounded

Found by a full cross-model re-read of [#800](https://github.com/HarperFast/harper-pro/pull/800) (branch `fix/replication-uniform-backoff`), recorded in that PR's description and deliberately not fixed there. **This is unmerged code** — if #800 addresses it before merge, close this. Unlike the sibling findings I traced end to end, this one is reported as read rather than independently verified.

## What is wrong

Before component readiness resolves, the worker-subscription admission map retains the latest action per connection key so it can be replayed once readiness lands. Terminal unsubscriptions are retained the same way.

No connection can exist before readiness, so a `subscribe` → `unsubscribe` pair for a key has nothing to undo: the retained work should be cancelled rather than dispatched. Because the unsubscribe is kept instead, every historic connection key leaves an entry behind. With a readiness promise that keeps rejecting, plus ordinary peer/database add-remove or URL churn, the map grows one tombstone per key that has ever existed and is never drained — potentially for the life of the process.

That is a bounded-storm change carrying an unbounded map, which is worth closing on principle even though the precondition (persistently rejecting component readiness) is not an everyday state.

## The shape of a fix

Make a pre-readiness unsubscribe **delete** its key rather than retain a terminal action, and cancel the armed re-attempt when the map becomes empty. Failing that, bound the retained-key set explicitly.

Refs #800, #327

Start at the worker-subscription admission map and its pre-readiness retry path, then compare the behavior described in #800 and #327. Verify that a pre-readiness subscribe/unsubscribe pair removes its key, cancels an armed retry when the map is empty, and prevents unbounded growth while readiness keeps rejecting.

Written by the indexing model from the issue text.