Allow updating resolver and resolving note of a decision

What does this MR do and why?

Allow updating resolver and resolving note of a decision

The user or comment recorded as resolving a decision can be wrong and needs correcting afterwards. Resolution fields are written by the resolve step, so a value set on an open decision would be silently overwritten on resolve; they are now limited to resolved decisions, and archived decisions reject updates altogether.

First of two MRs towards supporting the updating of options.

Related to #629049 (closed)

FE integration notes

This MR extends the existing workItemDecisionUpdate mutation (WorkItemDecisionUpdateInput). No new mutation, no new widget wiring needed.

New arguments

• resolvedById (UserID): updates who resolved the decision. Send only the user's Global ID now, e.g. gid://gitlab/User/123.
• resolvingNoteId (NoteID): updates id of the comment that resolved the decision.

New validation to handle

• resolutionRationale, resolvedById, and resolvingNoteId can now only be updated on RESOLVED decisions (resolvedAt set). Sending them on an open decision returns a payload error like Resolution rationale can only be updated on resolved decisions. This is a behaviour change: editing resolutionRationale on open decisions used to work (unintended oversight).
• ARCHIVED decisions (state: ARCHIVED) reject every update with Archived decisions cannot be updated. Hide or disable the Edit action for archived decisions.
• resolvedById: fails with Resolver must have access to the work item if the user lacks read access, or if the id doesn't resolve to a user.
• resolvingNoteId: fails with Note cannot resolve this decision if the note isn't a regular comment on the same work item, or if the id doesn't resolve to a note.

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 #629049 (closed)