Improve hawkbit Docker CI for PRs, releases, and fork compatibility

[wborn]

Summary

Refactor the hawkbit Docker image workflow to better support pull requests, forks, manual runs, and releases.

This change allows PRs to validate the Docker build without publishing, makes the workflow safer for fork-based contributions, adds container vulnerability scanning, and keeps release and manual publishing behavior explicit and predictable.

Changes

• add pull_request support for image validation
• add workflow_dispatch support for manual runs
• allow manual runs only on main or on a tag
• treat tag-based manual runs as versioned builds
• treat main branch runs as develop builds
• make image naming fork-friendly via vars.DOCKERHUB_NAMESPACE || github.repository_owner
• centralize image tag and version computation in a metadata step
• skip DockerHub login and publishing for PR builds
• build the image locally first for Anchore/Grype scanning
• upload SARIF results only for non-PR runs, and only for workflow_dispatch on main
• publish multi-arch amd64/arm64 images for trusted runs
• add Docker build cache configuration
• pin GitHub Actions to commit SHAs

Behavior

Pull requests

• build the image locally
• run Anchore/Grype scanning
• do not log in to DockerHub
• do not publish images
• do not upload SARIF results

Push to main

• build and publish the develop multi-arch image
• run Anchore/Grype scanning
• upload SARIF results

Release

• build and publish versioned multi-arch images
• publish latest alongside the versioned tag
• run Anchore/Grype scanning
• upload SARIF results

Manual dispatch

• allowed only on main or on a tag
• on main, behaves like a develop build
• on a tag, behaves like a versioned release build
• fails fast on any other ref

Why

These changes make the workflow more contributor-friendly by allowing PR validation without requiring publish credentials.

They also improve maintainability by centralizing tag computation and making the workflow behavior explicit for pushes, PRs, releases, and manual runs.

Finally, they add vulnerability scanning so issues in the image are surfaced during CI.

Notes

• the image is built locally once for scanning
• trusted runs still perform a separate multi-arch build for publishing
• Markdown-only changes do not trigger the workflow