RH24 accumulator is indexed incorrectly

### Brief summary of bug

FATES uses the `bc_in%relhumid24_pa` variable for relative humidity in its SPITFIRE fire danger calculations. This is a patch-level variable, but the value should be identical for all patches on a gridcell (or "site," in FATES parlance). However, some testing revealed that this is not the case: NGEET/FATES#1469.

I've figured out the reason for the discrepancy—in how patches are indexed to gridcells before the update/extraction of `RH24`—and how to resolve it. See below for details.

### General bug information

**CTSM version you are using:** ctsm5.3.075

**Does this bug cause significantly incorrect results in the model's science?** Yes, if the indexing of the first vegetated FATES patch is ever wrong.

**Configurations affected:** FATES runs using SPITFIRE.

### Details of bug

`bc_in%relhumid24_pa` is set in `CLMFatesInterfaceMod` `dynamics_drv()` here:
https://github.com/ESCOMP/CTSM/blob/2b375f9692039542328b4397f2b55f22cccfb621/src/utils/clmfates_interfaceMod.F90#L1266-L1279

`wateratm2lndbulk_inst%rh24_patch` is set in `Wateratm2lndBulkType` `UpdateAccVars()` here:
https://github.com/ESCOMP/CTSM/blob/2b375f9692039542328b4397f2b55f22cccfb621/src/biogeophys/Wateratm2lndBulkType.F90#L444-L449

See the difference in how patches are indexed to their gridcell? That turns out to be important. [Forcing the latter to behave like the former](https://github.com/ESCOMP/CTSM/commit/18d039ce22e206a2d22ae0729d8fd888bd92f138) solves the problem.

#### What about the other `bc_in%*24_pa` variables?
`bc_in%precip24_pa` and `bc_in%wind24_pa` seem to NOT have any within-site differences. I can see why that might be the case for precipitation, because it's downscaled to the column level before `PRECIP24` is updated:
https://github.com/ESCOMP/CTSM/blob/2b375f9692039542328b4397f2b55f22cccfb621/src/biogeophys/Wateratm2lndBulkType.F90#L412-L416
https://github.com/ESCOMP/CTSM/blob/2b375f9692039542328b4397f2b55f22cccfb621/src/biogeophys/Wateratm2lndBulkType.F90#L441-L442

However, I don't understand why `bc_in%wind24_pa` wouldn't have the issue, since `WIND24` is indexed the same way `RH24` was:
https://github.com/ESCOMP/CTSM/blob/2b375f9692039542328b4397f2b55f22cccfb621/src/main/atm2lndType.F90#L1008-L1013

> [!WARNING]
> Why doesn't `bc_in%wind24_pa` have the same problem?

### Important details of your setup / configuration so we can reproduce the bug

Tested with `ERS_D_Ld5.f10_f10_mg37.I2000Clm50Fates.derecho_intel.clm-FatesCold`, but [many other FATES tests (although not all)](https://github.com/NGEET/fates/issues/1469#issuecomment-3309940274) exhibit the same issue.

### Important output or errors that show the problem

When called from the test case or run directories, all of these commands give no results at [the commit that fixes RH](https://github.com/ESCOMP/CTSM/commit/18d039ce22e206a2d22ae0729d8fd888bd92f138) on my [rh-varies-by-patch branch](https://github.com/samsrabin/fates/tree/rh-varies-by-patch), but they give RH diffs of up to 87.7% with the commit before it on that branch.

**Find biggest RH diffs among patches at a site, from within FATES:**
```shell
grep -h "Max RH diff between patches" $(find . -type f -name "cesm.log*") | cut -d: -f 3 | sort -g | tail
```

**Find biggest RH diffs on VEGETATED patches at a site, from within FATES:**
```shell
grep -h "Max RH diff between veg patches" $(find . -type f -name "cesm.log*") | cut -d: -f 3 | sort -g | tail
```

**Find biggest RH diffs CLM-side on wateratm2lndbulk_inst:**
```shell
grep -h "Max CLM RH diff b/w patches" $(find . -type f -name "cesm.log*") | cut -d: -f 3 | sort -g | tail
```

**Find biggest RH diffs CLM-side on bc_in**
```shell
grep -h "Max bc_in RH diff b/w patches" $(find . -type f -name "cesm.log*") | cut -d: -f 3 | sort -g | tail
```