fix: Snapshot job action before awaiting its mutation to avoid race

What does this MR do and why?

Playing a manual job from the pipeline mini graph showed a spurious "There was a problem canceling the job" alert even though the job ran. The play mutation writes the job's new status into the Apollo cache, flipping actionType from play to cancel before the await resolves. The result was then destructured against the cancel action's data name, which is undefined, and the catch reported the cancel error.

This captures the action definition before awaiting so the result and error message always match the action that was triggered.

Changelog: fixed Closes #628688

Before / After

Before: Playing a manual job could show "There was a problem canceling the job" even though the job started — the mutation flipped actionType to cancel mid-flight, so the result was read against the wrong action and the catch used the cancel error message.

After: The action (mutation, data name, and error message) is snapshotted before the await, so the in-flight status change no longer misdirects the result read or the error message, and no spurious cancel alert appears.

How to set up and validate locally

1. Run the updated spec:

   yarn jest spec/frontend/ci/common/private/job_action_button_spec.js

2. Or in the UI: from a pipeline mini graph, play a manual job and confirm no "problem canceling the job" alert appears.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #628688