ndep_nflds needs to be set by CAM/WACCM when ndep is provided so CTSM uses the ndep from CAM

### What happened?

in current CLM: ctsm5_3_030, ndep_nflds needs to be set by CAM so that CTSM will use the ndep sent by it -- rather than the ndep it reads internally. This needs to be done for cases where ndep is calculated by CAM for sure. Eventually CLM will ensure it's set when coupled to CAM, but CLM needs to evaluate to make sure CAM/DATM are providing all the prescribed scenarios that are needed, and that answers don't change the climate from the current data that's used.

### What are the steps to reproduce the bug?

Setup a simple case with WACCM where ndep is going to be calculated, and show that there aren't any settings in the drv_flds_in file for the case.

This was noticed by Mariana on the CTSM side here:

https://github.com/ESCOMP/CTSM/issues/1900#issuecomment-2397244373

```
./create_test SMS.f19_f19_mg17.FWHIST_BGC.derecho_intel.cam-outfrq9s_waccm_mam4 -r . --walltime 00:20:00 --no-build
cd SMS.f19_f19_mg17.FWHIST_BGC.derecho_intel.cam-outfrq9s_waccm_mam4*
./preview_namelists
grep ndep CaseDocs/drv_flds_in # which shows nothing so the ndep fields won't be used inside of CTSM
```

I did this in a cesm3_0_alpha06b sandbox

### What CAM tag were you using?

cam6_4_067

### What machine were you running CAM on?

CISL machine (e.g. cheyenne)

### What compiler were you using?

Intel

### Path to a case directory, if applicable

_No response_

### Will you be addressing this bug yourself?

No

### Extra info

This is probably something that I should talk to whoever is going to do this on the CAM side, so we make sure CAM and CLM do the appropriate thing and will work correctly together.