Simplify events API for Duo Workflow

Problem

When we introduced the APIs to stream all workflow related updates to the LSP we took a shortcut to just send back all the raw checkpoint data to the LSP. This raw checkpoint data is an internal Langgraph representation of the state of the system and it's a big mess of JSON embedded in JSON and 90% of it is not relevant to the frontend.

When we first introduced these APIs we always intended to get around to more strictly defining these fields. Now after some time we still haven't done this and it makes it very difficult for frontend developers to work with our APIs (see https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/issues/921#note_2447486353) as the data is a gnarly JSON payload.

The large payloads are likely to cause a lot of slow down for users and have a noticeable egress cost for GitLab. For reference, with a simple goal of Create a file called hello.sh that prints hello I am finding that the total amount of data transferred in the GraphQL stream to the user is 3 MiB with the largest checkpoints getting to 150 KiB in size.

We believe this complicated data model is likely to introduce more bugs in future as well as slow down our frontend developers. We are also concerned that moving Duo Chat to use a similar architecture is going to multiply all these downsides and create a much greater technical debt to resolve.

Proposed Solution

As described at #535898 (comment 2449258433) we should be only sending the ui_chat_log part of our checkpoints to the client in our GraphQL API.

Other Possible Solutions

We should pick from one of the options:

1. Have the Rails backend parse out the relevant details and only serve those up from APIs. This was the original plan as we created a generically named WorkflowEventType which just embeds the checkpoint but we can always pluck the important fields and add them as top level fields and eventually remove the raw checkpoint field from this subscription API.
2. Have Duo Workflow Service take more responsibility of generating the user facing representation of what is going on and saving that to GitLab Rails separately from the lower level checkpoint metadata. That could be in the same API request but a different set of columns
3. Some other option that abstracts the frontend (LSP) away from the internal implementation details