Exact restart issue with `FATES_CBALANCE_ERROR` for logging tests only

[glemieux]

@rgknox I ran the full e3sm fates test list on perlmutter and found that we have a new exact restart error, but only for fates_cold_logging this time. The FATES_CBALANCE_ERROR is not B4B on the time step immediately following restart, but only for that timestep. All other later values for this variable are B4B.

 FATES_CBALANCE_ERROR   (lon,lat,time)  t_index =     33    33
          4     3312  (    58,    10,     1) (    24,    25,     1) (    59,    11,     1) (    63,    24,     1)
                1144   3.980355057296992E-17  -3.552713599391162E-17 5.3E-18 -1.583095810303794E-17 1.3E-03 -1.081439471957639E-17
                1144   3.980355057296992E-17  -3.552713599391162E-17         -1.056767817571509E-17         -5.551115205843844E-18
                3312  (    58,    10,     1) (    24,    25,     1)
          avg abs field values:    8.183425185801436E-18    rms diff: 3.1E-19   avg rel diff(npos):  1.3E-03
                                   8.165021244352744E-18                        avg decimal digits(ndif):  0.4 worst:  0.3
 RMS FATES_CBALANCE_ERROR             3.1122E-19            NORMALIZED  3.8074E-02

Since this addresses the initial NEP exact restart issue, I'm tempted to simply file a new issue and integrate this PR, especially since the restart error doesn't propagate over time. Note that we don't have this testmod in the e3sm_land_developer list so this won't show up in the integration tests for E3SM-Project/E3SM#7231, so it wouldn't hold things up from the E3SM integrator's perspective.

One other note: I recently ran the e3sm fates tests list for the API 41 update (E3SM-Project/E3SM#7665) and did not see this issue with fates_cold_logging.

Results: e3sm-tests/pr7231-1448-fates.fates.pm-cpu..Eea69a01050-Ff847ef79

Originally posted by @glemieux in #1448 (comment)

[rgknox]

Thanks for documenting this @glemieux. I think there are a few things that can still be cleaned up with restarting site level fluxes and boundary conditions with the HLM, hopefully that cleanup addresses this.