Improve handling of changing calendar type in a branch run

@briandobbins pointed me to a CISL help desk ticket that was opened last week where a user was getting the following output:

PET log:
```
20250508 001420.236 ERROR PET000 (lnd_comp_nuopc):(ModelAdvance) CTSM clock not in sync with Master Sync clock
20250508 001420.274 ERROR PET000 LND:src/addon/NUOPC/src/NUOPC_ModelBase.F90:2218 Failure - Passing error in return code
```

LND log:
```
ctsm ymd= 20240301 ctsm tod= 0
sync ymd= 20240229 sync tod= 0
```

I dug into this a bit, leading me to the following message that I sent to Brian:

> I think I understand what's happening here: CTSM thinks it's using a NOLEAP calendar, whereas the model as a whole is using a GREGORIAN calendar. This is apparent in various log files if you `grep -i` for "calendar".
>
> I think the reason that's happening is because this is a branch run, which means that a bunch of stuff is read from the restart file, including time information, which includes the calendar type. The restart file used here was from a run with a NOLEAP calendar, so CTSM reads that calendar type from the restart file and this overwrites the calendar type that came from the driver (GREGORIAN in this case).
>
> I think a solution would be for the user to do a hybrid instead of branch run in this case, if that's acceptable for their setup. I think that a hybrid case will lead to the model using the driver's time information rather than the time information on the restart file.
>
> This suggests something that should be changed in CTSM: At the very least, we should do some consistency checking between the driver calendar and the restart file's calendar. It's possible that we should ignore the calendar on the restart file and just use the driver's calendar, but I'm not sure if that will work reliably, so a first step would be at least adding this consistency check. I'll open an issue about this.

The last paragraph raises the need that I see: In a restart or branch run, CTSM sets the calendar type from the restart file. At the very least, this should be checked for consistency with the calendar type obtained from the driver to ensure that the two are consistent. It's possible that CTSM should ignore the calendar type on the restart file and just use the calendar type from the driver, but this could warrant some analysis / thought to determine whether this could cause problems in some circumstances - such as counters of elapsed time steps since some baseline that would become incorrect when changing the calendar type.