fix: add admin pull request state reconciliation endpoint

[mertilginoglu]

Motivation

Open pull requests can remain stale in Helios when GitHub state changes are missed or delayed. This makes the local PR state unreliable for reviewers and administrators and makes it harder to recover from synchronization gaps.

Description

• add an admin-only pull request state reconciliation endpoint for a repository, including optional dryRun support
• add a reconciliation service and result DTO that:
  • loads locally open pull requests for a repository
  • checks their current state on GitHub
  • reprocesses pull requests that are already closed on GitHub
  • reports updated, unchanged, missing, and failed reconciliations
• extend error handling so authorization failures on the new endpoint are returned as 403 Forbidden
• add focused tests for:
  • the reconciliation service behavior
  • controller authorization and dryRun handling
  • pull request sync cutoff behavior in the GitHub data sync orchestrator
• include minor supporting cleanup in related server files

Testing Instructions

Prerequisites:

• local server environment for Helios
• a repository connected to Helios
• one admin user and one non-admin user
• a repository ID with pull requests available in Helios

Flow:

1. Run the targeted server tests for the new reconciliation flow and controller coverage.
2. Start the application server locally.
3. As a non-admin user, call POST /api/pullrequests/repository/{repositoryId}/reconcile-state and verify the request is rejected with 403 Forbidden.
4. As an admin user, call POST /api/pullrequests/repository/{repositoryId}/reconcile-state?dryRun=true and verify the response contains reconciliation statistics without modifying data.
5. Call POST /api/pullrequests/repository/{repositoryId}/reconcile-state as an admin user and verify that pull requests which are locally open but already closed on GitHub are reconciled correctly.
6. Verify that missing GitHub pull requests are counted as missing and unexpected GitHub/API failures are reported as errors in the response.

Checklist

General

• PR description explains the purpose and changes. (f.e. following the 'Conventional Commits') (https://www.conventionalcommits.org/en/v1.0.0/)
• Changes have been tested locally.

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
✅ +1.38% (target: -1.00%)	✅ 83.72%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (730ef52)	8130	2402	29.54%
Head commit (de3eaa2)	8216 (+86)	2541 (+139)	30.93% (+1.38%)

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 (#900)	86	72	83.72%

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 17e6515db6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[meryemefe]

I have a general comment: In local tests, I got 403 first. Then, I realized that admin authorization requires X-Repository-Id header, so we will get 403 without it even if we have admin access rights. It would be good to document it for next developers. Maybe we can also think about an Admin Dashboard for such operations.

[mertilginoglu]

I have a general comment: In local tests, I got 403 first. Then, I realized that admin authorization requires X-Repository-Id header, so we will get 403 without it even if we have admin access rights. It would be good to document it for next developers. Maybe we can also think about an Admin Dashboard for such operations.

I added a new service to check repository related authorization. I noticed that in previous case admins in different repos can run this endpoint also for other repositories.