Workplan: decide what should count as a genuine work_item_agent_plan_read

Summary

!257324 (merged) stops mutation responses (saves) from firing the work_item_agent_plan_read internal event. That fix only addresses the GraphQL layer: today the event fires whenever a query resolves content/contentHtml on AgentPlanType, regardless of whether a human actually viewed the plan.

Follow-up discussion from !257324 (merged)#note_3896142569 and !257324 (merged)#note_3896321980 raised open questions about what should actually count as a "read":

  • Should the event instead (or additionally) be tracked from the frontend, for example when the user opens the plan view (URL includes ?show=workplan), rather than relying purely on the GraphQL field being selected?
  • Does the current backend tracking also count API calls that fetch agentPlan through coding tools or other non-UI consumers as reads, even though no human viewed the content?

Proposal

Decide the intended semantics of work_item_agent_plan_read:

  1. Should it represent "the GraphQL field was resolved" (current backend-only approach), or "a human viewed the plan in the UI" (frontend-driven), or both tracked as distinct events?
  2. If non-UI/API consumers (for example coding tools calling the GraphQL API directly) should be excluded or tracked separately, define how to distinguish them.
  3. Update tracking accordingly, and document the intended meaning of the metric so future changes don't reintroduce ambiguity.

Context

Edited by 🤖 GitLab Bot 🤖