Clarify completion scheduler semantics for timed scheduler fallbacks

まず PR #2164 と issue #847 を確認し、その後、この issue にある timed scheduler の fallback に関する疑問を追跡します。completion-scheduler クエリ、cv/ref の動作、receiver environments、lazy now() について意図された契約を明確にします。完了とは、契約とその結果としてのスコープが明示的に決定されていることを意味します。

Related: #2164

PR #2164 restores get_completion_scheduler<set_value_t> on the lazy fallbacks for schedule_at and schedule_after.

The implementation can inspect the type of the completion scheduler returned by the native timed sender, but then returns the scheduler passed into the fallback. This is correct if timed_scheduler requires native timed operations to complete on that exact scheduler value. However, timed_scheduler currently only requires schedule_at and schedule_after to return senders.

For example, a scheduler S{context_a} could return a sender whose completion scheduler is S{context_b}. The types match, but the execution resources do not. The fallback would advertise context_a even though the native sender completes on context_b.

There is also a cv/ref question. The native sender type is probed using _Scheduler, but the actual call happens later from a non-mutable lambda and sees the captured scheduler as const S&. Ref-qualified overloads can therefore produce a different native sender type from the one inspected by the fallback.

Could we clarify the intended contract?

1. If schedule_at and schedule_after must complete on the supplied scheduler value, should timed_scheduler document or require that?
2. If not, should the fallback omit the completion-scheduler query unless equality can be established?
3. Should the fallback also preserve completion-scheduler queries that depend on the receiver environment, or is that out of scope?

The fallback must keep now() lazy. Issue #847 explains why computing the native sender eagerly is not equivalent.