Replace DuoWorkflowAction with assign-based trigger for "Generate MR with Duo" button

What does this MR do?

Replaces the DuoWorkflowAction component on the work item detail page with a new DuoAssignDeveloperButton that uses the assign trigger path instead of directly sending a goal to the workflow.

Previously, the "Generate MR with Duo" button constructed a goal (the work item URL) and passed it directly to the workflow with a hardcoded developer/v1 workflow definition and agent privileges. Now it simply assigns the Duo Developer service account to the work item, which triggers the developer flow through the existing assign event path — the same path used when you manually assign the service account.

This is the frontend counterpart to !231681 (merged) (backend goal template routing). The two MRs are independent and can be merged in any order.

Key changes

File	Change
ee/.../duo_assign_developer_button.vue (new)	Replaces DuoWorkflowAction — assigns the service account instead of sending a goal directly
ee/.../get_duo_developer_service_account.query.graphql (new)	Query to discover the service account GID from configured flow triggers
app/.../work_item_detail.vue	Swapped DuoWorkflowAction for DuoAssignDeveloperButton, removed agentPrivileges

What changed in behavior

Before	After
Button sent workItem.webUrl as goal directly to developer/v1 workflow	Button assigns service account → assign trigger fires → goal constructed server-side
Hardcoded workflow-definition="developer/v1" and agentPrivileges in template	Discovers service account dynamically via aiCatalogConfiguredItems query
Button always visible when duoRemoteFlowsAvailability was true	Button only visible when a flow with an assign trigger and service account is configured
Replaced all assignees	Appends service account to existing assignees

Design decisions

• Separate component (not inlined): work_item_detail.vue is a CE file. The button depends on EE-only imports (getDuoDeveloperServiceAccount query, FLOW_TRIGGER_TYPE_ASSIGN constant), so it must use the ee_component import pattern
• Append vs replace assignees: The mutation appends the service account to existing assignees using a Set for deduplication, rather than replacing all assignees
• No magic numbers: Uses FLOW_TRIGGER_TYPE_ASSIGN.valueInt from the shared constants instead of hardcoded 1

Related: #574990

How to set up and validate locally

Prerequisites

• A Duo Developer trigger configured on a test project with the developer/v1 flow with an assign event type

Test 1: Button visible — happy path

1. Go to an issue/work item that has a developer/v1 flow configured with an assign trigger
2. Verify: The "Generate MR with Duo" button is visible
3. Click the button
4. Verify: The Duo Developer service account appears in the assignees (existing assignees are preserved)
5. Verify: The assign flow triggers automatically

Test 2: Button hidden — no assign trigger

1. Edit the flow trigger to only have the mention event type (remove assign)
2. Go to the same issue
3. Verify: The button is not visible
4. Re-add the assign event type and refresh — Verify: The button reappears

Test 3: Button hidden — no flow configured

1. Go to an issue in a project with no developer/v1 flow configured
2. Verify: The button is not visible

Test 4: Existing assignees preserved

1. Assign a human user to the issue
2. Click the "Generate MR with Duo" button
3. Verify: Both the human user and the Duo Developer service account are now assigned