Rebuild Docker images weekly to pick up security patches

[markof88]

Right now, Docker images only rebuild when a new version is tagged. If nothing gets tagged for a while, the images can end up with old, unpatched system packages (like curl), for example, CVE-2026-8925 is fixed upstream in Ubuntu's curl package, but v8.6.3 predates that fix and won't pick it up until a new release is cut.

This adds a weekly scheduled rebuild for the rolling v{major}-latest tag, so it stays patched even between releases. It does not touch or change the fixed version tags (like v8.6.3)

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[snipe]

Hi there - thanks for this! Can you please re-target this PR to point to the develop branch, per our Contributing documentation?

You don't usually need to close and re-open. After you create a pull request, you can modify the base branch so that the changes in the pull request are compared against a different branch. By changing the base branch of your original pull request rather than opening a new one with the correct base branch, you’ll be able to keep valuable work and discussion.

If you change that branch and you see bunch of someone else's commits in the "files changed" tab of this PR, you might need to rebase. (Leaving those changes in can make it kinda confusing to see this PR actually changes.)

To Rebase

Assuming you started with this repo as the origin, and added yourself as a named remote:

git fetch origin; git rebase origin/develop

otherwise git fetch whatever your remote is.

Thanks!

[markof88]

Thanks for the pointer, done! Rebased onto develop and retargeted the PR