lfric2um levels mismatch between lfric and um for area cloud fraction

### Version

main

### Are there any linked Issues or Pull Requests?

_No response_

### What happened?

STASH code 265 Area cloud fraction in a layer in the UM is mapped to `area_fraction` in `lfric_atm`.

In the UM, the level type is theta levels (full levels). The LevelF code is 1 meaning the first level is the first atmospheric level which misses off level 0. Compare with 266 Bulk cloud fraction which is on theta levels but whose LevelF code is 40, meaning it has one extra level at level 0.

In LFRic, both fields are on `full_level_face_grid` which is analogous to theta levels, and so both fields have the same number of levels as 266 but one more level than 265.

The level code suggests that 265 misses level 0. Examining the original UM data from the um2lfric test, it looks like um2lfric duplicates the data in the first and second LFRic level. **This implies that lfric2um needs to ignore the first LFRic level of 265**.

lfric2um does not take the LFRic level number into account when gathering LFRic data: it assumes the number of UM levels is the same as the number of LFRic levels. As a result, the regrid of data is corrupt. Note, this showed up as differences in the field when running on different numbers of ranks or when running with a different stencil depth (which changes the number of halo points in the distributed field).

A quick test set the value of the level number input in the call to `lfricinp_gather_lfric_field` to `num_levels + 1` for `stashcode == 265` and the output then looked perhaps more correct (previously, the output looked very different from the bulk cloud field and now it looks similar), but it is also identical between changing stencil size from 1 to 2 and changing ranks from 6 to 12.

Need to see how um2lfric handles this, and construct a better way of identifying the difference (e.g. checking the levels for both UM and LFRic).

### Relevant log output

```shell

```

Trace the lfric2um path and the lfricinp_gather_lfric_field call, focusing on how the level number is passed for STASH code 265. Compare this with the um2lfric handling and the level metadata for fields 265 and 266. Done means the level mapping is identified without relying on a hard-coded assumption, and results remain consistent across stencil depths and MPI rank counts.

Written by the indexing model from the issue text.