Preserve service test results across PR edits

[LitoMore]

Why

The Services workflow currently listens to pull_request.edited. Description-only edits create a skipped test-services check, which replaces the previous real result in the PR UI. Giving the skipped job a different name can conflict with the required test-services check, while rerunning service tests on every edit can exhaust API rate limits.

What

• Stop triggering Services for pull_request.edited
• Keep the existing opened, reopened, synchronize, and merge-queue behavior
• Fetch the current PR title from the GitHub API when selecting service tests
• Allow an existing Services run to be rerun after a title edit using the latest title

After changing a PR title, a maintainer can rerun the existing Services workflow. Description edits leave the previous real test-services result intact.

[github-actions]

	Messages
📖	✨ Thanks for your contribution to Shields, @LitoMore!

Generated by 🚫 dangerJS against 98d2770

[PyvesB]

After changing a PR title, a maintainer can rerun the existing Services workflow.

How so? Would I need to locate the right job, open it in the Actions interface, and click on some buttons to retry?

I occasionally get the title wrong (latest example in date being #12083) and contributors regularly forget it. What I like with the existing workflow is that it's extremely low overhead, just modify the title, and it will launch the job.

[LitoMore]

Yes, you have to rerun the job from its details page.

There are no separate events for PR title changes and PR description changes.

Feel free to close this PR if you prefer our current implementation.

[PyvesB]

I like the existing setup, but I've really not got a very strong opinion. Let's let @jNullj be the tie breaker. :)

[jNullj]

Can i suggest the following:

• We run the test on every change like today to keep the low overhead
• We add a new first step that checks if the change requires a new run
  • If title changed and changes includes text inside [ brackets ]
  • Or if base branch updated (part of this event)
• If it does - run tests and show results, If it does not - skip the rest of the steps and use the last results
  • I assume here we can use an API call to fetch the last run results

I hope this sounds reasonable as its a bit more complex.
If you both still aim for simplicity, I think i prefer what we use today as i value our time over our api quota.