[2425] Publish multi-platform Docker images

[ctrahey]

Fixes #2425.

The eclipsesyson/syson Docker images are currently linux/amd64 only, requiring arm64 users (Apple Silicon, AWS Graviton) to force emulation via DOCKER_DEFAULT_PLATFORM=linux/amd64 (#991). Since the jar is architecture independent and built outside Docker, multi-platform publishing needs only:

• docker/setup-qemu-action (SHA-pinned, same version line as the existing buildx action) before the Buildx setup, and
• platforms: linux/amd64,linux/arm64 on the existing push step.

The test image built with load: true for Playwright/Cypress stays single-arch/native, so those jobs are unaffected. The amd64 half of the pushed image reuses the Buildx cache from the test build; the arm64 half builds under QEMU, which only runs the apk add and adduser layers.

Validated locally: docker buildx build --platform linux/amd64,linux/arm64 of the unmodified backend/application/syson-application context completes for both platforms, and the arm64 image runs SysON natively against the standard docker-compose setup.

Also updates the Apple Silicon workaround notes in the installation guide, docker-compose.yml, CHANGELOG.adoc, and the 2026.9.0 release notes to reflect that the workaround only applies to older releases.

Bug: #2425

PLEASE READ ALL ITEMS AND CHECK ONLY RELEVANT CHECKBOXES BELOW

Auto review

• Have you reviewed this PR? Please do a first quick review, It is very useful to detect typos and missing copyrights, check comments, check your code... The reviewer will thank you for that :)

Project management

• Has the pull request been added to the relevant milestone?
• Have the priority: and pr: labels been added to the pull request? (In case of doubt, start with the labels priority: low and pr: to review later)
• Have the relevant issues been added to the pull request?
• Have the relevant labels been added to the issues? (area:, type:)
• Have the relevant issues been added to the same project milestone as the pull request?

Changelog and release notes

• Has the CHANGELOG.adoc + doc/content/modules/user-manual/pages/release-notes/YYYY.MM.0.adoc been updated to reference the relevant issues?
• Have the relevant API breaks been described in the CHANGELOG.adoc?
• Are the new / upgraded dependencies mentioned in the relevant section of the CHANGELOG.adoc?
• In case of a change with a visual impact, are there any screenshots in the doc/content/modules/user-manual/pages/release-notes/YYYY.MM.0.adoc?
• In case of a key change, has the change been added to Key highlights section in doc/content/modules/user-manual/pages/release-notes/YYYY.MM.0.adoc?

Documentation

• Have you included an update of the documentation in your pull request? Please ask yourself if an update (installation manual, user manual, developer manual...) is needed and add one accordingly.

Tests

• Is the code properly tested? Any pull request (fix, enhancement or new feature) should come with a test (or several). It could be unit tests, integration tests or cypress tests depending on the context. Only doc and releng pull request do not need for tests.

[ctrahey]

Working on the ECA - sent an email to help me unstick my eclipse account but when that happens I'll kick off the check again.

[ctrahey]

Thanks for the approval! Rebased and ECA is signed :-)