Improve spawn/spawn_future diagnostics for invalid senders

[Cra3z]

Improve spawn/spawn_future diagnostics for invalid senders in the selected environment. For example:

ex::spawn(task() | ex::upon_error([](auto) noexcept {}), scope.get_token());

ex::spawn(
  ex::starts_on(ex::get_parallel_scheduler(), task()) | ex::upon_error([](auto) noexcept {}),
  scope.get_token()
);

The diagnostic overload currently reports:

spawn expects a sender that cannot fail 

This is misleading because the underlying problem may be unrelated to set_error. For example:

auto foo() -> ex::task<>
{
  co_return;
}

ex::starts_on(ex::get_parallel_scheduler(), foo()) is invalid because ex::task_scheduler is incompatible with ex::parallel_scheduler.

This change separates the two cases:

• invalid wrapped sender: delegate to the existing sender diagnostics;
• valid sender with a set_error completion: retain the existing spawn expects a sender that cannot fail diagnostic.

This could make the error message more user-friendly for cases like issue #2309.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.