fix(cluster): replay every subscription handler to a joining server

[Gabriellji]

What does this PR do?

Closes #29

ClusteredRedisQueue remembered one { channel, handler } pair, so each
subscribe() overwrote the previous one. Handlers still reached the servers
already in the cluster — which is why this stays invisible while membership is
stable — but a server joining later was replayed only the last-registered
handler.

With one handler carrying business events and another carrying cache
invalidation, such a host serves the second and silently drops the first. The
socket stays subscribed, the publisher still sees a subscriber, RPC is
unaffected and health checks pass, so nothing surfaces the loss.

Every registration is now remembered and installed, in registration order,
including the same function registered twice (subscribe() stays additive as
IMessageQueue documents). The live subscribe() path and the catch-up for a
joining server became one serialised operation per host, so a handler cannot be
installed twice.

Three smaller fixes fall out of the same code:

• a server that failed to start while joining produced an unhandled
  rejection — a process exit on current Node defaults. It is now consumed
  where it is already reported.
• a host added before start() could be left unstarted when the cluster was
  started a microtask later, because the decision to start was taken inside a
  deferred body whose promise had already been cached.
• destroy() now closes admission synchronously, settles a send() parked
  waiting for its first server, and attempts every cleanup task independently so
  one failure cannot strand the rest.

Type of change

• Bug fix
• New feature
• Documentation
• Refactor / internal
• Other:

Checklist

• I have read the Contributing guide.
• Tests added or updated, and the full suite passes locally (npm test).
• Docs / doc-blocks updated where relevant.
• The PR is focused on a single logical change.

How it was verified

• npm test — 413 pass.
• npm run test-integration — 6 specs drive a real broker and assert
  deliveries rather than mocked calls. They skip with a reason where no broker
  answers, and npm test does not run them, so CI is unaffected.
• Each test was calibrated by running it against v3.5.1 and against a
  no-serialisation variant and confirming it fails there. Every guard was
  mutation-tested individually: removing any one of them fails at least one
  test.
• Reproduced end-to-end on a service before and after: a host joining after both
  registrations carried one handler; it now carries both.

Note on release level

Not a patch. subscribe() now rejects a bad channel on an empty cluster where it
previously resolved, subscribe()/unsubscribe() serialise per host, and a
destroyed instance rejects work it used to accept. All are in CHANGELOG.md
under ### Changed.

Known limitation, unchanged by this PR

An imq.start() already in flight cannot be cancelled, so a stop() arriving
mid-start can still leave a stopped cluster with a started host. Verified
present in v3.5.1 as well; out of scope here.

Contribution terms (required)

• I have read and agree to the @imqueue Contribution Terms.

[github-actions]

All contributors have signed the @imqueue Contribution Terms. ✅
_{Posted by the CLA Assistant Lite bot.}

[Mikhus]

Thank you for the contribution. This is really good change. Please, sign CLA so I can merge it

[Gabriellji]

I have read the CLA Document and I hereby sign the CLA