Missing frontend logic concerning DR P0929R2 and unevaluated contexts

```c++
// https://godbolt.org/z/Kra4E7GPe
// GCC 15 with C++20 doesn't compile. Clang 22 with C++20 compiles.
// In short, GCC is strictly conforming to the standard, and Clang is non-conforming.
// http://eel.is/c++draft/expr.prop#basic.lval-9
// "Unless otherwise indicated ([dcl.type.decltype]), a prvalue shall always have complete type or the void type; if it has a class type or (possibly multi-dimensional) array of class type, that class shall not be an abstract class ([class.abstract])."

// The code simply looks like this:

struct X { virtual void f() = 0; };

// #1
template concept returnable = requires (T f()) { f(); }; // Clang doesn't check anything about `f()' other than `destructible', by the way. One may also notice that std::destructible is true, because declval().~X() in all unevaluated contexts is valid, this might be a gotcha moment.
static_assert(returnable, "GCC is correct.");

// #2
X(*f)() noexcept = nullptr;
decltype(noexcept(f())) g(); // error in `GCC`
decltype(f()) h(); // [dcl.type.decltype]: "The type of the prvalue may be incomplete or an abstract class type."
static_assert(noexcept(f())); // error in GCC
```

Start with the provided C++20 reproducer and compare GCC 15 with Clang 22. Read the referenced [basic.lval] and [dcl.type.decltype] wording, then trace the frontend handling of the requires expression, noexcept, and decltype cases. Done means the affected cases follow the standard behavior and have regression coverage.

Written by the indexing model from the issue text.