[BUG]: STF constructs such as parallel_for do not accept lvalue (extended) lambda functions

### Is this a duplicate?

- [x] I confirmed there appear to be no [duplicate issues](https://github.com/NVIDIA/cccl/issues) for this bug and that I agree to the [Code of Conduct](CODE_OF_CONDUCT.md)

### Type of Bug

Compile-time Error

### Component

CUDA Experimental (cudax)

### Describe the bug

While the usual idiom is to pass lambda function as rvalues like this

```
ctx.parallel_for(shape, deps...)->*[](size_t i, auto a, auto b) {
...
};
```

We may want to pass an lvalue instead :

```
auto fn = [](size_t i, auto a, auto b) {
...
};
ctx.parallel_for(shape, deps...)->*fn;
```

But STF currently makes the assumption that we have an rvalue and does invalid operations such as moving instead of forwarding. The mechanisms used to differentiate host/device/host device lambdas are also not working as expected, resulting in compilation errors, or runtime bugs as we fail to call the appropriate parallel_for implementation.

### How to Reproduce

```
auto fn = [](size_t i, auto a, auto b) {
...
};
ctx.parallel_for(shape, deps...)->*fn;
```

### Expected behavior

rvalues and lvalues should behave the same.

### Reproduction link

_No response_

### Operating System

_No response_

### nvidia-smi output

_No response_

### NVCC version

_No response_