feat: track release creators and show deploy source branch

[mertilginoglu]

Motivation

Release candidate details currently do not expose who created the underlying GitHub release, which makes it hard to distinguish the release publisher from the release candidate creator. The deploy confirmation dialog also lacks the source branch/ref, so reviewers do not get enough context before triggering a deployment. #621

Description

• Persist the release creator for newly synced/published releases and expose it via ReleaseDto and the generated OpenAPI client.
• Show the release creator separately on the release candidate details page, including avatar fallback handling.
• Pass the release candidate branch through the deployment flow and display it in the deploy confirmation dialog, with fallback to the release candidate name when no branch is available.
• Add backend and frontend tests covering creator persistence, DTO mapping, release details rendering, and deploy dialog source-ref behavior.

Testing Instructions

Prerequisites:

• Helios running with server and client changes from this branch
• A repository that has a release candidate and a synced or newly published GitHub release
• Maintainer/Admin access for publishing a release and triggering a deployment
• Developer access for verifying the read-only release candidate details view

Flow:

1. Log in to Helios and open a release candidate details page for a release that was created or synced after this change.
2. Verify the page still shows the release candidate creator and now also shows a separate release created by entry for the published release creator.
3. As a Maintainer/Admin, open the deploy action for that release candidate and verify the confirmation dialog shows Branch to deploy with the release candidate branch.
4. Repeat with a release candidate that has no branch metadata and verify the dialog falls back to the release candidate name.
5. Publish a new release draft from Helios or trigger a GitHub release sync, then reopen the release candidate details page and verify the release creator is populated for the newly created release.

Screenshots

Checklist

General

• PR description explains the purpose and changes. (f.e. following the 'Conventional Commits')
• Changes have been tested locally.
• Screenshots have been attached.

Server

• Code is performant and follows best practices
• I documented the Java code using JavaDoc style.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.80% (target: -1.00%)	✅ 57.14%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (f1ef92d)	8066	2306	28.59%
Head commit (259ab0c)	8116 (+50)	2385 (+79)	29.39% (+0.80%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#905)	28	16	57.14%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

[meryemefe]

LGTM, thank you for fix!