fix: handle existing todo scenario for todoCreate GraphQL mutation

What does this MR do and why?

References

This MR fixes a bug in the todoCreate GraphQL mutation where calling the mutation on a target that already has a pending todo for the same user caused the mutation to fail with the error:

{
  "data": {
    "todoCreate": null
  },
  "errors": [
    {
      "message": "Cannot return null for non-nullable field TodoCreatePayload.errors"
    }
  ]
}

Screenshots or screen recordings

Before	After
{   "data": {     "todoCreate": null   },   "errors": [     {       "message": "Cannot return null for non-nullable field TodoCreatePayload.errors"     }   ] }	{   "data": {     "workItemCreate": {       "workItem": {         "id": "gid://gitlab/WorkItem/615",         "iid": "38",         "title": "test work item created from GDK"       },       "errors": []     }   },   "correlationId": "01KB87S35TBX2VHSYPMEF0B1B0" }

How to set up and validate locally

1. Enable the feature flag in Rails console Feature.enable(:namespace_level_work_items)

2. Create a group level work item with the following query at http://127.0.0.1:3000/-/graphql-explorer so you can fetch a work item in the next query

   mutation {
      workItemCreate(input: {namespacePath: "flightjs", title: "test group level work item", workItemTypeId: "gid://gitlab/WorkItems::Type/1"}) {
        errors
        workItem {
          id
          iid
        }
      }
    }

3. Fetch a wok item by IID and request the WorkItemWidgetLinkedItems field

    mutation {
      todoCreate(input: {targetId: "<id_returned_in_previous_step>"}) {
        errors
        todo {
          action
          author { username }
          target {
            webUrl
          }
          targetType
        }
      }
    }

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.