Fix run_loop sender's zero-environment completion signatures

[steve-downey]

run_loop::sender::get_completion_signatures<Self, Env...>() evaluates get_stop_token(std::declval<Env>()...). For an empty Env pack that is get_stop_token() with no argument, which is ill-formed. Because the member's return type is deduced, determining the type of the call requires instantiating the body, so the error is not in the immediate context: it is a hard error rather than a substitution failure.

[exec.getcomplsigs] constrains sizeof...(Env) <= 1, so the zero-environment query is well-formed and has to be answered. Two consequences of it not being:

• get_completion_signatures<decltype(schedule(sched))>() fails to compile.
• dependent_sender is itself spelled in terms of that query inside a requires-expression, so dependent_sender<run-loop-sender> is ill-formed rather than false -- and every algorithm that reaches for it fails with it. when_all over two run_loop senders does not compile today for this reason.

Answer the empty pack as for env<>. That is what [exec.run.loop]'s own formula gives for E = env<>, whose stop token is unstoppable, and it is how the other environment-sensitive senders here already handle the empty pack -- then_t and into_variant_t both carry

template <typename Sender>
struct get_signatures<Sender> : get_signatures<Sender, env<>> {};

The header branch also gains #include <detail/env.hpp>; the modules branch already imported beman.execution.detail.env.

Both new assertions in exec-run-loop-types.test.cpp fail to compile against the unfixed header, which is what makes them a regression test rather than a restatement.

[coveralls]

coverage: 93.487%. remained the same — steve-downey:fix/run-loop-zero-env-complsigs into bemanproject:main

[steve-downey]

This amount of comment is probably not actually warranted.