Add TestKitBase.ShutdownAsync and adopt it in StressSpec churn teardown

[Aaronontheweb]

Closes #8497.

Problem

TestKitBase.Shutdown is a blocking Terminate().Wait(duration). On a loaded agent that pins a thread-pool thread for the whole wait, while the work the shutdown is waiting on — coordinated-shutdown phases, cluster heartbeats — competes for the threads that remain. In StressSpec's join-remove churn phase the wait ran its full 10s and starved the hosting node's own heartbeat sender for 12+ seconds, so the survivors marked it unreachable and SBR downed it mid-test. The wait made its own timeout more likely.

Change

New API, purely additive — two overloads on TestKitBase, mirroring the sync pair exactly (same access modifiers, parameter names, defaults, forced-guardian-stop fallback, and throw-vs-log rule for verifySystemShutdown):

public virtual Task ShutdownAsync(TimeSpan? duration = null, bool verifySystemShutdown = false);
protected virtual Task ShutdownAsync(ActorSystem system, TimeSpan? duration = null, bool verifySystemShutdown = false);

The timeout race reuses AwaitWithTimeout from Akka.TestKit.Extensions — no new timer plumbing. The only observable difference from the sync path is that a faulted Terminate() surfaces its exception unwrapped instead of inside an AggregateException.

Both paths share one private force-stop tail, so the sync and async behavior cannot drift. The sync Shutdown keeps its own Terminate().Wait rather than blocking on the async one: sync-over-async would pin a thread and need two pool continuations scheduled while it is held — strictly worse under the starvation this fixes.

StressSpec adopts it at both churn teardown sites (in-loop and post-loop). Same wait budget, same fallback, same ordering relative to the settle block and the churn barriers — the wait just no longer holds a thread. StressSpec now contains no calls to the blocking Shutdown.

Tests

Three new deterministic tests in ShutdownAsyncTests. The timeout cases are not time-bounded guesses: a coordinated-shutdown task returns a TaskCompletionSource the test controls, so Terminate() genuinely cannot complete until released.

1. Awaiting ShutdownAsync leaves WhenTerminated completed — catches a fire-and-forget regression.
2. verifySystemShutdown: true + a stuck system throws TimeoutException naming the system.
3. verifySystemShutdown: false + a stuck system logs the same message as a Warning and does not throw.

Verification

• ShutdownAsync tests: 3/3, repeated 5×, all green.
• Full Akka.TestKit.Tests: 327 passed, 1 pre-existing skip, 0 failed.
• Akka.API.Tests: 18/18 after the additive approval update (two lines added per approval file, nothing removed or changed).
• Akka.TestKit, Akka.TestKit.Tests, Akka.Cluster.Tests.MultiNode at -warnaserror: 0 warnings.

A full local StressSpec run is impractical — it needs ten node processes and reproduces only under the 2-vCPU starvation the issue describes — so the churn-site change rides on the clean build plus the API-behavior tests, and CI's MNTR lanes carry the live proof.

[Aaronontheweb]

Triage for the Linux Artery MNTR lane failure (build 130892): pre-existing flake, unrelated to this diff.

The lane failed on exactly one spec, Akka.Cluster.Sharding.Tests.DDataClusterShardingSpec. Node third hit the real failure — Timeout 00:00:05 while waiting for a message of type System.Int32 in the shard-restart phase — and the other four nodes then failed the after-shard-restart barrier behind it.

Evidence this is ambient:

• The same spec failed the same lane with the same shape on dev build 130792, before this branch existed.
• This PR touches TestKitBase (additive ShutdownAsync overloads) and StressSpec. DDataClusterShardingSpec uses neither; the sync Shutdown path it does use is byte-identical in behavior (only the shared force-stop tail was factored out).
• StressSpec — the one MNTR spec this PR modifies — is absent from the failure artifact, i.e. it passed on this lane.

The classic Linux MNTR lane published a failure-logs artifact too, but its TRX files contain no failed results and the lane reported green — a first-attempt failure that passed on retry.

Logging DDataClusterShardingSpec (artery Linux, 2 recent occurrences: 130792, 130892) as a candidate for the next de-flake wave.

[Aaronontheweb]

Triage for the two Linux MNTR failures on build 130907: same pre-existing flake family, both lanes, unrelated to this diff.

Both Linux lanes failed on one spec each — PersistentClusterShardingSpec, the persistence-mode variant of the ClusterSharding_specs mega-spec:

• Artery lane: node third, Timeout 00:00:05 waiting for Int32, barrier after-shard-restart — byte-for-byte the signature DDataClusterShardingSpec produced on build 130892 (and 130792 on dev), just in the sibling variant.
• Classic lane: node fourth, Timeout 00:00:13.8 waiting for Int32, barrier after-13 — a different phase of the same spec, same counter-round-trip shape.

Why this cannot be the PR:

• ClusterShardingSpec.cs contains no calls to Shutdown or ShutdownAsync at all.
• The only changes in this run vs. the previous one (where classic Linux passed) are the dev merge — which brought De-flake ClusterSingletonProxySpec, ClusterSingletonRestartSpec, and DistributedPubSubRestartSpec #8498, touching only Akka.Cluster.Tools tests — and the deletion of one redundant unit test.
• The same family has now failed four lane-runs across three builds, two of which predate this branch's current content.

Running tally for the ClusterShardingSpec family: DData variant on artery Linux (130792, 130892), Persistent variant on both Linux lanes (130907). This is the strongest candidate for the next de-flake wave; the recurring shape is an Int32 counter read racing shard recovery after a region restart.

Will retrigger CI once this build settles.