fix(ateapi): drop worker watch events instead of stalling pub/sub

[NekoPunch (orangeCatDeveloper)]

Fixes #624

Under heavy worker churn the worker cache silently serves a stale worker list
for up to a full relist interval — long enough to schedule actors onto workers
that no longer exist, with nothing in the logs or metrics saying so.

Root cause

WatchWorkers forwards pub/sub messages into a 128-event channel with a
blocking send. A slow consumer fills it, the forwarding goroutine parks on
ch <- event and stops reading the socket, and Valkey evicts the subscriber for
overrunning its pub/sub output buffer:

Client id=7 ... flags=P ... omem=41008 lib-name=go-redis(,go1.26.3)
  scheduled to be closed ASAP for overcoming of output buffer limits.

The eviction never reaches us: go-redis reconnects and resubscribes underneath,
closing its message channel only on pool.ErrClosed. So there is no closed watch
and no resync — queued and in-flight events are simply gone while ready stays
true. Quieter and worse than #624 assumed: not a scheduling outage, but
silently wrong scheduling input.

The fix

Overflow drops the event, counts it, and raises a coalesced
WorkerWatch.Invalidated signal instead of blocking, so the socket keeps
draining and Valkey has no cause to evict. workercache reads that as "relist
now", first draining events that predate the drop (they would roll the fresh
snapshot back). A failed relist retries on a 100ms→5s backoff instead of waiting
for the periodic ticker; a successful resync or periodic relist cancels a pending
retry. The old snapshot keeps serving throughout — no ready=false window.

The PostgreSQL store keeps its blocking send (nil invalidation channel): its
LISTEN consumer has no equivalent server-side eviction.

Evidence

Real Valkey 8, client-output-buffer-limit pubsub 32kb 8kb 3, stalled consumer,
50000 events (~6MB), fresh container per run:

	before	after
client_output_buffer_limit_disconnections	1	0
invalidation signal	none	SIGNALED
ate.store.worker_watch.dropped_events	no metric	49872

Cache recovery after a lost DELETE, at the production 5-minute relist interval:

before  corrected_after=NEVER (>10s; waits for the 5m relist)
after   corrected_after=6ms