2026.07.2 release reports its version as 2026.07.1

Nobody has claimed this yet.

## Summary

The `2026.07.2` release reports itself as `2026.07.1`. The top-level `CMakeLists.txt` was not bumped when the release was tagged, and that value is what feeds both the generated pkg-config file and the `get__version()` functions.

## Detail

At tag [`2026.07.2`](https://github.com/MetOffice/shumlib/blob/2026.07.2/CMakeLists.txt#L17-L18):

```cmake
project(shumlib LANGUAGES C Fortran
VERSION 2026.07.1
```

That flows into two places a consumer would look:

- `cmake/shumlib.pc.in` → the installed `lib/pkgconfig/shumlib.pc` reports `Version: 2026.07.1`.
- `SHUMLIB_VERSION`, built by the `string(CONCAT ...)` immediately below, which backs the `get__version()` functions.

So a build of `2026.07.2` is indistinguishable from `2026.07.1` by either mechanism.

Both `main` and `stable` currently still carry `VERSION 2026.07.1`, so the bump appears to have been missed rather than applied and reverted.

## Suggested fix

Bump `project(... VERSION ...)` to match the release being tagged. Since this is tied to your release process rather than a code defect, I have not raised a PR for it — happy to do so if you would like the version on `main` moved to `2026.07.2`.

It might also be worth having CI assert that `project(VERSION)` matches the tag being built, so a future release cannot be cut without the bump.

## How this surfaced

I hit this while packaging shumlib for conda-forge (conda-forge/staged-recipes#34717), where the packaged version and the version the library reports disagreed. The recipe currently carries a patch correcting it locally.

Update the VERSION in the top-level CMakeLists.txt from 2026.07.1 to the version being released. Read cmake/shumlib.pc.in and the nearby SHUMLIB_VERSION string concatenation to confirm both reported-version paths use the project version. Done means the generated pkg-config file and get__version() functions report 2026.07.2.

Written by the indexing model from the issue text.