Chore: handle mealie API change

[joncrangle]

Proposed change

Mealie is introducing breaking API changes that are already merged in the "nightly" builds. See mealie-recipes/mealie#3970. The groups/statistics endpoint is being deprecated and replaced with a households/statistics API.

I modelled the API handling on the Immich implementation #2284. If the version starts with "v2", or equals "nightly" it will use the new endpoint. Otherwise, it will keep using the existing endpoint to ensure this is non-breaking for people who pin to a v1 build.

Closes #

Type of change

• New service widget
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Documentation only
• Other (please explain)

Checklist:

• If applicable, I have added corresponding documentation changes.
• If applicable, I have reviewed the feature and / or service widget guidelines.
• I have checked that all code style checks pass using pre-commit hooks and linting checks.
• If applicable, I have tested my code for new features & regressions on both mobile & desktop devices, using the latest version of major browsers.

[shamoon]

Thanks. We’re going to start moving away from doing it this way because this will cause errors in one case or the other while the version call is pending.

Instead, the way to do this is use the version parameter in the widget config. And to be non-breaking it’ll need to default to the current one.

Not as “clean” for sure, but for widgets that don’t use a proxy it’s how we’ll handle stuff like this.

Let me know if that makes sense, and if you can make the changes

[shamoon]

Thanks for the PR.

Note: this didn't actually work without my last commit there, always good to test things out. (I did of course):

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns. See our contributing guidelines for more details.