Fetch agent plan widget via standalone query

What does this MR do and why?

This MR splits the Work Item "agent plan" (workplan) widget out of the main namespaceWorkItem GraphQL query into its own standalone query, following the same pattern already used by other widgets (Development, Linked Items, Participants).

The namespaceWorkItem query is already at the GraphQL query complexity cap (250 for authenticated non-admin users). Adding any new field to the agent plan (specifically an upcoming aiPlanningEnabled boolean) tips it over to 251, which breaks the query for non-admin users. Admins have a higher cap (300), so this was not caught in manual testing.

This behavior-preserving refactor removes the agent plan content/contentHtml from the main query, reducing complexity, and fetches content on demand via a dedicated query + subscription. There is no user-facing behavior change on master.

It unblocks the follow-up MR !250010 (merged), which adds the aiPlanningEnabled field and the "Plan" CTA.

Related:

• Discussion where this split was suggested: !250010 (merged)#note_3728014804
• Issue for the dual-fetch complexity bloat: #587972

How to set up and validate locally

1. Ensure that there is no workplan widget when the F agent_plan is turned off
2. Enable the FF agent_plan
3. Open a Work Item that has an agent plan
4. Confirm the plan content loads and renders
5. Edit and save the plan; confirm the change persists
6. Delete the plan; confirm it is removed
7. Confirm real-time updates still arrive via the subscription
8. Enable the FF work_item_features_field and repeat the steps above

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.

Related to #608883 (closed)