Draft: Render Workplan Flow questions as interactive cards in work item discussions

⚠️ This MR is just PoC

This MR is just a playground to test changes from WS-2 through WS-4 in a single branch, it is not intended to be merged. As we get closer to GA, parts of this MR will separately make its way into master and this MR will be closed.

What this does

Note: This MR depends on following two MRs, while everything lives behind workplan & duo_workplan_async_flow feature flags:

• gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!6364 (closed)
• !247170 (closed)

Both the above MRs allow for Workplan Flow to post questions as asked by Duo Agentic Chat during Workplan generation to be posted on Work Item Discussions. This MR attaches a small machine-readable block to its comment, which the frontend can parse and present it as an interactive UI that user can respond to.

As soon as user responds, next run of the flow reads that reply and treats it as a settled decision rather than an assumption. So the loop closes without anything having to wait around, making the discussion async.

Demo

Workplan Flow Changes

Besides the changes made in gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!6364 (closed), we also need to update the prompt in flow config such that it can include machine-readable blob of JSON in the comment body (inspiration taken from !248340 (closed)), which can in turn be parsed on frontend to present interaction UI.

Diff against workplan/1.0.0.yml from ai-assist!6364

--- a/duo_workflow_service/agent_platform/v1/flows/configs/workplan/1.0.0.yml
+++ b/duo_workflow_service/agent_platform/v1/flows/configs/workplan/1.0.0.yml
@@ -151,6 +151,39 @@ prompts:
         briefly in Assumptions, one line each, alongside the interim
         assumption the plan proceeds under for that item.
 
+      ### Comment format
+
+      Write the question as ordinary prose first — that is what a human reads
+      in email, in the API, and if the page's JavaScript never runs. Then
+      append one fenced block describing the same question in machine-readable
+      form, so the work item UI can offer the choices directly:
+
+      ```json:duo-question
+      {"type": "closed", "question": "<the same question, one sentence>",
+       "options": [
+         {"id": "snake_case_id", "label": "Short label",
+          "description": "One sentence on what this option means and its trade-off.",
+          "recommended": true}
+       ]}
+      ```
+
+      - `type` is `closed` when you can enumerate the realistic answers, and
+        `open` when you cannot. Use `open` for anything needing a number, a
+        name, a link, or free prose.
+      - For `closed`, give 2 or 3 mutually exclusive options, exactly one of
+        them with `recommended: true`. Omit `options` entirely for `open`.
+      - The block is the only place the options belong. Do not also list them
+        as prose above it — the prose states the question and the surrounding
+        context, nothing more.
+      - The block must contain complete, valid JSON on a single line. Never
+        emit an empty or partial block.
+      - Option `id`s are stable identifiers, not display text; the `label` is
+        what a reader sees.
+      - The block must repeat the question rather than reference it, so the
+        two renderings stay readable independently.
+      - Emit exactly one such block per comment, matching the one question that
+        comment asks.
+
       ## Plan format
 
       Produce Markdown with a **Why / How / What** structure: