Return success when status update target already matches

What does this MR do and why?

We have logs such as

'Can not require_input workflow that has status tool call approval required'
'Can not require_tool_call_approval workflow that has status tool call approval required'

These are causing unnecessary failures.

With this MR, status update endpoint returns success if the workflow already has the target status.

References

Closes gitlab-org/modelops/applied-ml/code-suggestions/ai-assist#1178 (closed)

Screenshots or screen recordings

How to set up and validate locally

Example:

1. Create a workflow

   curl POST --verbose \
    --header "Authorization: Bearer $GDK_TOKEN" \
    --header 'Content-Type: application/json' \
    --data '{
        "project_id": "flightjs/test-duo", "goal": "My goal", "agent_privileges": [1,2,5]
    }' \
    http://gdk.test:3000/api/v4/ai/duo_workflows/workflows

2. Start the workflow

curl --request PATCH --verbose \
    --header "Authorization: Bearer $GDK_TOKEN" \
    --header 'Content-Type: application/json' \
    --data '{
        "status_event": "start"
    }' \
    http://gdk.test:3000/api/v4/ai/duo_workflows/workflows/1526

3. Send one more request to start (it's already in status: start)

curl --request PATCH --verbose \
    --header "Authorization: Bearer $GDK_TOKEN" \
    --header 'Content-Type: application/json' \
    --data '{
        "status_event": "start"
    }' \
    http://gdk.test:3000/api/v4/ai/duo_workflows/workflows/1526

You should not receive 400.

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.