test: isolate SendConsistency specs into separate JVM forks

[He-Pin]

Motivation

ArteryTlsTcpSendConsistencyWithOneLaneSpec flakes on CI because it creates 2 ActorSystems with TLS-TCP transport and runs 1000 round-trip message exchanges via ActorSelection. When other test classes run in the same forked JVM (the remote module uses a single fork), lingering ActorSystem threads from previous tests consume CPU and compete with the TLS operations, causing the test to exceed its 60-second timeout (30s × timefactor=2).

Even with Test / parallelExecution := false, test classes share the same JVM and their ActorSystem cleanup threads (TLS connections, scheduler threads, dispatcher pools) overlap.

Modification

Add Tests.Group configuration to the remote module that partitions *SendConsistency* test classes into their own SubProcess (forked JVM), while keeping all other remote tests in a shared "other" group:

Test / testGrouping := {
  val allTests = (Test / definedTests).value
  val (sendConsistencyTests, otherTests) =
    allTests.partition(_.name.contains("SendConsistency"))
  val defaultForkOptions = ForkOptions()
    .withRunJVMOptions((Test / javaOptions).value.toVector)
  val otherGroup = Tests.Group("other", otherTests, Tests.SubProcess(defaultForkOptions))
  val sendConsistencyGroups = sendConsistencyTests.map { t =>
    Tests.Group(t.name, Seq(t), Tests.SubProcess(defaultForkOptions))
  }
  otherGroup +: sendConsistencyGroups
}

Each of the 6 SendConsistency specs gets a clean JVM with no thread contention from previously-run test classes.

Result

SendConsistency specs run in isolated JVM forks, eliminating cross-test thread contention that caused the 1-lane TLS-TCP variant to flake. Other remote tests continue to share a single fork (no additional overhead).

Tests

sbt -Dpekko.test.timefactor=2 "remote / Test / testOnly
  *ArteryTlsTcpSendConsistencyWithOneLaneSpec" — 4/4 passed

sbt "show remote / Test / testGrouping" — verified 6 SendConsistency
  groups + 1 "other" group

References

Refs #3089

[He-Pin]

Closing: fork isolation helps with JVM-internal contention but the 1-lane SendConsistency flakiness is caused by CI host-level CPU contention (confirmed same test also fails on origin/main without this change). The lane distribution fix in #3092 is the more impactful change for the multi-lane variants.