[i18n] Tracked `.mo` binaries conflict on every parallel i18n PR

## Friction

#4092 reduced the `.po`-side merge conflicts, but all 14 `.mo` binaries still produce conflicts.
Because binaries can't be merged textually, parallel PRs that run `compile_catalog` conflict on the regenerated `.mo` files.
The fix is mechanical (re-run `compile_catalog`, re-stage) but the conflict recurs on every i18n PR.

## Question

Is tracking `.mo` intentional?
It looks like they're tracked to be shipped via sdist/wheel:

https://github.com/dgtlmoon/changedetection.io/blob/7831a499b25c018533773e9eee8378a6f6bdb53f/MANIFEST.in#L15

## Possible direction

Meanwhile, the `Dockerfile` already runs `pybabel compile` on every build, so the tracked `.mo` files are overwritten there:

https://github.com/dgtlmoon/changedetection.io/blob/7831a499b25c018533773e9eee8378a6f6bdb53f/Dockerfile#L123

With a `compile_catalog` step in CI, `.mo` would be generated at build time, mirroring Docker.

https://github.com/dgtlmoon/changedetection.io/blob/7831a499b25c018533773e9eee8378a6f6bdb53f/.github/workflows/pypi-release.yml#L21-L22

Alternatively, hooking `compile_catalog` into `BuildPyCommand.run()` in `setup.py` might also work.

Could `.mo` then be untracked?