Clarify completion scheduler semantics for timed scheduler fallbacks

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.

Review PR #2164 and issue #847 first, then trace the timed scheduler fallback questions in this issue. Determine the intended contract for completion-scheduler queries, cv/ref behavior, receiver environments, and lazy now(). Done means the contract and resulting scope are explicitly decided.