pubsub: bound announce retry attempts

[Sahil-4555]

Issue

This PR fixes an unbounded retry path in subscription announcements.

When a node subscribes or unsubscribes from a topic, PubSub sends an announce RPC to all connected peers. If a peer's outbound queue is already full, that send fails with ErrQueueFull and PubSub schedules announceRetry.

Earlier, this retry path did not have any limit. If the peer stayed connected but kept its outbound queue full, every failed retry would schedule one more retry again. This was not proved as an active goroutine leak, because each retry goroutine exits after scheduling the next attempt. But still, one failed announce could keep retrying forever as long as that peer stayed under queue pressure.

This is a PubSub library issue, not something applications can fix cleanly. The application does not own the per-peer outbound queue, does not call announceRetry, and has no way to limit this retry chain from outside. The retry policy belongs to PubSub's internal peer and subscription lifecycle, so the bound should also live inside PubSub.

This can happen in a real production setup with a slow or stalled peer. For example, a peer may stop reading from its stream, read very slowly, or keep its outbound queue saturated while the local node is doing normal subscribe/unsubscribe work. In that case, PubSub should not keep retrying the same announce forever. Dropping the retry after a small number of attempts is fine, because the peer can still learn topic state later through normal pubsub traffic and heartbeat behaviour.

Fix

This change adds a small retry budget to announceRetry.

Each failed announce retry now carries an attempts counter. If the peer queue is still full after the retry budget is used, PubSub drops that retry instead of scheduling another one. If the queue has space before the budget is exhausted, the retry succeeds exactly as before.

The change keeps the existing behaviour intact:

• retries still go through p.eval
• retries still check the current local topic state before sending
• retries still stop when the PubSub context is cancelled
• disconnected peers are still ignored
• the peer outbound queue remains non-blocking
• tracing still records dropped and sent RPCs

So this bounds the retry work without changing mesh behaviour, scoring, validation, message propagation, or shutdown semantics.

Tests

This PR adds TestAnnounceRetryStopsAfterLimit.

The test fills a peer outbound queue, runs the announce retry path with an exhausted retry budget, then frees queue space and checks that no late announce is sent afterwards. This verifies the main issue directly: once the retry limit is reached, the same failed announce does not keep rescheduling forever.

The existing TestAnnounceRetry still covers the happy path where a retry succeeds and the subscription announce is delivered.