Remove duplicate namelist variables

[SeanBryan51]

This change removes duplicate module variables for namelist options l_casacnp, l_landuse, l_laiFeedbk, and l_vcmaxFeedbk.

Cherry-picked from #655

Type of change

Please delete options that are not relevant.

• Bug fix

Checklist

• The new content is accessible and located in the appropriate section
• I have checked that links are valid and point to the intended content
• I have checked my code/text and corrected any misspellings

Testing

• Are the changes bitwise-compatible with the main branch? If working on an optional feature, are the results bitwise-compatible when this feature is off? If yes, copy benchcab output showing successful completion of the bitwise compatibility tests or equivalent results below this line.

2026-02-24 11:49:25,946 - INFO - benchcab.benchcab.py:380 - Running comparison tasks...
2026-02-24 11:49:25,982 - INFO - benchcab.benchcab.py:381 - tasks: 168 (models: 2, sites: 42, science configurations: 4)
2026-02-24 11:52:24,750 - INFO - benchcab.benchcab.py:391 - 0 failed, 168 passed

Spatial runs are also bitwise compatible:

nccmp -d runs/spatial/tasks/crujra_access_R*_S0/archive/output000/cable_out.nc
nccmp -d runs/spatial/tasks/crujra_access_R*_S1/archive/output000/cable_out.nc
nccmp -d runs/spatial/tasks/crujra_access_R*_S2/archive/output000/cable_out.nc
nccmp -d runs/spatial/tasks/crujra_access_R*_S3/archive/output000/cable_out.nc

---

📚 Documentation preview 📚: https://cable--692.org.readthedocs.build/en/692/

[Whyborn]

Just making sure I understand what was going on- these had definitions in both cable_common and cable_driver_common, which weren't necessarily in sync? There's never any logical reason to have the SAVE attribute on module variables right?

[SeanBryan51]

Just making sure I understand what was going on- these had definitions in both cable_common and cable_driver_common, which weren't necessarily in sync?

Yes

There's never any logical reason to have the SAVE attribute on module variables right?

Nope, pretty sure SAVE is implied for module variables

[Whyborn]

Nope, pretty sure SAVE is implied for module variables

Yea, that's what I thought. Confusing stuff.