Add workflow_dispatch entry point to gradle-check workflow

[bzhangam]

Description

Adds a manual, write-access-only workflow_dispatch trigger to the gradle-check workflow so changes to the workflow (and the gradle check command it runs) can be tested from a branch before merging to the default branch. This is the first step toward splitting the gradle check into parallel segments (#19378).

• Add workflow_dispatch trigger with 'ref' and 'gradle_check_command' inputs.
• Make the gradle-check job runnable on dispatch (bypass the PR-diff gate, tolerate the skipped Code-Diff-Analyzer, and check out the dispatched ref).
• Skip the PR-only Code-Diff-Analyzer / Code-Diff-Reviewer jobs on dispatch.
• Pass an optional gradle_check_command through to the Jenkins runner via the existing -c flag, using an env var and quoted array args to avoid script injection and word-splitting.
• Fail check-result if a dispatched gradle-check fails.

Related Issues

#19378

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

PR Code Analyzer ❗

AI-powered 'Code-Diff-Analyzer' found issues on commit b553685.

⛔ Hard block: Issues at Medium severity or above will block this PR from merging.

Path	Line	Severity	Description
.github/workflows/gradle-check.yml	155	medium	GITHUB_ENV injection risk: `ref_input` is set from user-supplied `github.event.inputs.ref` and then interpolated unquoted/unsanitized into multiple `echo '...' >> $GITHUB_ENV` lines (pr_title, pr_or_commit_description). A value containing a newline (e.g. `main%0AMALICIOUS_VAR=evil`) would inject arbitrary environment variables into subsequent steps. While workflow_dispatch requires write access, this is still an unintended escalation path.
.github/workflows/gradle-check.yml	170	medium	User-controlled command forwarded to Jenkins: `gradle_check_command` input is passed as `-c "$DISPATCH_GRADLE_CHECK_COMMAND"` to the Jenkins webhook script. If the Jenkins-side script executes this value in a shell context without sanitization, a write-access user could inject arbitrary commands into the Jenkins runner. The attack surface is gated by write access, but the -c flag provides an explicit vector for influencing remote execution.
.github/workflows/gradle-check.yml	96	low	Checkout of an arbitrary user-supplied ref: `actions/checkout` uses `github.event.inputs.ref` directly as the checkout ref. A write-access user could supply a ref pointing to any commit or tag, including ones not yet reviewed, potentially causing the runner to build and test unreviewed code with access to repository secrets. This is the documented intent of the feature but widens the trust boundary.

The table above displays the top 10 most important findings.

Total: 3 | Critical: 0 | High: 0 | Medium: 2 | Low: 1

---

Pull Requests Author(s): Please update your Pull Request according to the report above.

Repository Maintainer(s): You can bypass diff analyzer by adding label skip-diff-analyzer after reviewing the changes carefully, then re-run failed actions. To re-enable the analyzer, remove the label, then re-run all actions.

---

⚠️ Note: The Code-Diff-Analyzer helps protect against potentially harmful code patterns. Please ensure you have thoroughly reviewed the changes beforehand.

Thanks.