[BUG]: Combining proclaim_return_type and make_zip_function breaks in certain cases

### 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

Not sure

### Describe the bug

With CCCL 2.2.0 it was possible to combine these two on a device lambda to take input from a `zip_iterator`. Since CCCL 2.3.x/CUDA 12.4 this does not work anymore when returning a `thrust::tuple` and the order is
```cuda
thrust::make_zip_function(
cuda::proclaim_return_type>(
[] __device__ (...) {...}))
```
Swapping the two seems to have solved the issue for me, i.e.
```cuda
cuda::proclaim_return_type>(
thrust::make_zip_function(
[] __device__ (...) {...}))
```

The compiler error is
```
/opt/compiler-explorer/cuda/12.4.1/bin/../targets/x86_64-linux/include/cuda/functional:92:26: error: could not convert 'cuda::std::__4::__invoke<__nv_dl_wrapper_t<__nv_dl_tag >&, int, int>(((cuda::__4::__detail::__return_type_wrapper, __nv_dl_wrapper_t<__nv_dl_tag > >*)this)->cuda::__4::__detail::__return_type_wrapper, __nv_dl_wrapper_t<__nv_dl_tag > >::__fn_, (* & cuda::std::__4::forward((* & __as#0))), (* & cuda::std::__4::forward((* & __as#1))))' from 'int' to 'cuda::std::__4::tuple'
92 | return _CUDA_VSTD::__invoke(__fn_, _CUDA_VSTD::forward<_As>(__as)...);
| ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| int
```

### How to Reproduce

The reproducer is basically a one-liner. I chose to `thrust::tuple` as both output and input of the device lambda which is just an identity operation here.

I also needed to combine this construct with an actual `thrust::zip_iterator` for the compiler error to materialize in the reproducer. Therefore I added a combination of `transform_iterator`, `zip_iterator` and `counting_iterator`s.

```cuda
auto iter = thrust::make_transform_iterator(
thrust::make_zip_iterator(
thrust::make_counting_iterator(0),
thrust::make_counting_iterator(42)),
thrust::make_zip_function(
cuda::proclaim_return_type>(
[] __device__ (int a, int b){
return thrust::make_tuple(a, b);
})));
```

### Expected behavior

It would be nice if this would compile independent of order as it has with CCCL 2.2.0. Naively the failing ordering seems to make more sense because then the compiler knows what return type the `zip_function` should "inherit".

### Reproduction link

https://cuda.godbolt.org/z/McznoKnGx

### Operating System

_No response_

### nvidia-smi output

_No response_

### NVCC version

_No response_