[backport camel-spring-boot-4.18.x] CAMEL-24502: Least privilege for the sync workflows and pin the Maven wrapper downloads

[Croway]

Adapts #1930 for camel-spring-boot-4.18.x.

Original PR: #1930 — Least privilege for the sync workflows and pin the Maven wrapper downloads
JIRA: CAMEL-24502

What applies on this branch

Both automatic-sync-main.yml and generate-sbom-main.yml exist on this branch, as leftover
copies from before the branch was cut — they still check out and target main (ref: main,
base: main), not camel-spring-boot-4.18.x. That pre-existing quirk is a separate,
non-security concern and is left untouched here; this PR only addresses the permission gap.

Because the two files had diverged from main's (older actions/checkout, actions/setup-java
and peter-evans/create-pull-request tags), a straight git cherry-pick -x of the original
commit conflicted on both workflow files. I aborted the cherry-pick and hand-applied the same
pattern instead, keeping this branch's existing action version tags (no version bumps):

• permissions: {} declared at the workflow level on both files.
• The single job in each is split into build (contents: read — checks out and builds
  apache/camel then camel-spring-boot, so it must not hold any write grant, and uploads the
  regenerated diff as a build artifact) and create-pull-request (contents: write,
  pull-requests: write — downloads and applies the artifact, then calls
  peter-evans/create-pull-request; it runs no third-party build code).
• Every uses: reference in both files is pinned to a full commit SHA with the existing version
  tag kept as a trailing comment.

Worth noting for reviewers: automatic-sync-main.yml only has a schedule trigger, and GitHub
only fires scheduled workflows from the copy on the repository's default branch, so this file is
currently unreachable from a non-default branch like this one. generate-sbom-main.yml also
declares workflow_dispatch, so it can be manually dispatched against this branch and was a
real, reachable instance of the permission gap this ticket fixes. Both are hardened here for
consistency and defense in depth, even though one of them is presently dead code.

Maven wrapper pinning

.mvn/wrapper/maven-wrapper.properties on this branch points at the exact same
distributionUrl (apache-maven-3.9.11-bin.zip) and wrapperUrl
(maven-wrapper-3.3.4.jar) as main's pre-fix file. I independently downloaded both artifacts,
computed their SHA-256 sums with shasum -a 256, and cross-checked them against the .sha1
files published alongside them on repo.maven.apache.org — they match main's committed values.
Added distributionSha256Sum and wrapperSha256Sum in the same format as main.

Verification

• Both modified workflow YAML files parse cleanly (ruby -ryaml -e 'YAML.load_file(...)', PyYAML
  wasn't available in this environment).
• No Java or Maven module was touched, so no mvn build/test run was needed for this ticket.

Claude Code on behalf of Federico Mariani