test: pin read_env's completion-behavior claims for get_scheduler() (#2098)

[alwaysprince05]

A regression guard for the co_await path in #2098.

read_env may advertise inline completion only for the completion tags it can
actually send. It advertised more than that before 9a301946, so a task that
co_awaits

get_scheduler() | let_value([](auto sch) { return schedule(sch); })

was classified as completing inline. The awaiter then kept the composed
operation state in its own stack frame while a nested schedule() operation was
still queued, which is the lifetime bug reported in #2098.

These assertions pin the current behaviour:

• get_scheduler() claims inline completion for set_value_t — read_env
  completes in its start();
• it does not claim set_error_t or set_stopped_t, which it never sends;
• the composition above is not __as_awaitable::__completes_inline.

All three hold on current main and fail at 482c2605, so a regression of the
completion-behaviour claim is caught at compile time rather than as a crash.
Type-level rather than a runtime test, so it needs no sanitizer to be
deterministic.

Since __completes_inline has to consider every tag, the single-tag form is not
sufficient here — the two read_env claims and the composition are checked
separately so a failure says which one moved.

Built and run with Apple clang 21, -std=c++20, in both configurations:
test.stdexec passes 630 test cases / 50088 assertions with and without
STDEXEC_ENABLE_EXTRA_TYPE_CHECKING against the current base, no new warnings,
clang-format clean.

[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.