refactor(mpi): channel persistent requests

[dssgabriel]

Description

Specialize the MPI Channel implementation to manage persistent MPI requests directly as raw MPI_Request handles.

This removes temporary request containers and handle copies from start() and wait(), ensures persistent requests are released correctly, and preserves registered operations across Channel reuse and moves.

• Related issue(s): Closes Rework Channel to use raw persistent MPI requests #265
• Depends on: none

Additional context

The previous implementation stored persistent requests in separate send and receive vectors using the non-persistent Request<MpiSpace> abstraction.

Every communication cycle then created temporary containers and copied or moved request handles before calling the MPI collective request APIs.
It also did not release the persistent requests with MPI_Request_free.

The specialized implementation stores send and receive requests in a single registration-ordered vector of raw persistent handles.
It calls MPI_Startall and MPI_Waitall directly on that vector, reuses a preallocated status vector, and releases the requests when the Channel is destroyed or replaced through move assignment.

Changes

• Affected areas: mpi, unit tests, perf tests
• Breaking change(s)? no

List:

• Specialize Channel<MpiSpace> for the MPI backend.
• Store persistent send and receive operations together as raw MPI_Request handles.
• Start and wait on the registered requests without allocating temporary work vectors.
• Retain completion statuses in a reusable vector.
• Release persistent requests with MPI_Request_free.
• Transfer registered requests safely during Channel move construction and move assignment.
• Document Channel ownership, lifetime, registration-order, and reuse semantics.
• Cover host and default execution spaces, repeated communication cycles, and Channel moves.
• Expand the Channel point-to-point benchmark across payload sizes and registered operation counts.

Performance impact

The benchmark registers all persistent send and receive operations once, outside the timed loop, and measures repeated Channel::start()/Channel::wait() cycles.

It covers:

• Payload sizes from 1 B to 8 MiB.
• 1, 2, 4, 8, and 16 send/receive operation pairs.
• 45 configurations in total.

For a fair comparison, the new benchmark source was applied unchanged to clean snapshots of the develop branch (which only contained the previous fixed-size Channel benchmark).

Both snapshots were built in Release mode using the same Spack environment:

• GCC 15.3
• MPICH 5.0 (2 ranks pinned to separate CPU cores)
• Kokkos 5.0 (OpenMP backend, 1 thread/rank)

Representative mean results (on my laptop):

Configuration	This PR	develop	Time reduction
1 B, 1 pair	0.836 µs	1.441 µs	42.0%
1 B, 8 pairs	3.406 µs	6.167 µs	44.8%
4 KiB, 16 pairs	11.609 µs	20.459 µs	43.3%
8 MiB, 16 pairs	20.636 ms	21.289 ms	3.1%

This branch is faster in all configurations.
Configurations up to 32 KiB averaged a 40.7% reduction in median time.
As expected, the relative improvement decreases for larger payloads, as communication time comes to dominate the request-management overhead.

The develop run also reported unfreed inactive persistent requests during MPI finalization.
Those diagnostics occurred outside the timed region and confirm the persistent-request lifetime issue that this refactor addresses.

Checklist

• Tests are up-to-date
• Documentation is up-to-date