Disassociate the wrapped handle when a throttled association stops

[Aaronontheweb]

Closes #8637

Problem

ThrottlerHandle.Disassociate() only sent a PoisonPill to its ThrottledAssociation actor. That actor never disassociated the wrapped AssociationHandle, so with the trttl adapter applied (every MultiNodeSpec applies [trttl, gremlin]), the underlying TCP socket stayed open on both peers until the transport's Shutdown eventually force-closed it, instead of a graceful close.

Fix

ThrottledAssociation now disassociates the wrapped handle from PostStop (in a try/finally, so base.PostStop() always runs), so it happens exactly once no matter why the actor stopped (explicit disassociate, Blackhole, a crash, or transport shutdown). This mirrors canonical Akka's ThrottledAssociation.postStop, which does the same unconditional call and relies on the wrapped handle's Disassociate() being idempotent (a documented contract of AssociationHandle.Disassociate) - so there's no double-disassociate risk if the peer already tore the connection down first. Two call sites that used to disassociate the wrapped handle directly, and would now double up with PostStop, were removed.

Throttle mode behavior (Blackhole, TokenBucket) is otherwise unchanged - except that a new inbound association that gets blackholed during the handshake now closes its TCP socket as part of stopping, so the peer fails fast instead of waiting out the handshake timeout. This matches JVM Akka.

Testing

Added two tests to ThrottlerManagerLifecycleSpec, using its existing stub transport/handle harness, and strengthened an existing one:

• explicit ThrottlerHandle.Disassociate() now tears down the wrapped handle
• an inbound Disassociated notification (peer closed first) still disassociates the wrapped handle exactly once, via PostStop
• the pre-existing "payload before handle" test now also asserts the wrapped handle is disassociated exactly once, guarding against the removed redundant call site regressing

All three fail on dev (or would, in the strengthened case) and pass with this change. Ran ThrottlerTransportAdapterSpec + the new/updated tests 5x, and the full Akka.Remote.Tests Transport namespace once - all green. Also ran a couple of MultiNode specs locally (AttemptSysMsgRedeliverySpec, RemoteNodeShutdownAndComesBackSpec) - both pass; no measurable termination-time change was observed locally, which is expected since DotNettyTransport.Shutdown (post-#8635) only waits on handles that already started a graceful close, so previously-unclosed throttled handles weren't being waited on either - this fix makes them close gracefully instead of via force-close, without changing the shutdown wait.

Test-infrastructure only: trttl isn't applied in default configs (applied-adapters = []).

[Aaronontheweb]

LGTM