Automate CODEOWNERS ingestion and team expansion for agentic issue triage

[nagilson]

Related PR discussion

Follow-up from #55244.

Review discussions:

• Question about update cadence and ownership for the embedded team membership snapshot: [Experiment] Agentic Triage Workflow  #55244 (comment)
• Reply noting that this should eventually be automated and tracked as follow-up work: [Experiment] Agentic Triage Workflow  #55244 (comment)
• Discussion about making ownership/load-balancing data deterministic and avoiding manual PAT rotation: [Experiment] Agentic Triage Workflow  #55244 (comment)
• Reply noting the token and CODEOWNERS expansion work should be improved together: [Experiment] Agentic Triage Workflow  #55244 (comment)

Background

The agentic issue triage workflow reads the repository's CODEOWNERS ownership model through prompt instructions and includes a static expanded team membership snapshot so it can turn CODEOWNERS team matches into individual assignment candidates.

The current CODEOWNERS interpretation and team snapshot were manually prepared and embedded in the workflow prompt. This is useful for initial validation, but it can drift as CODEOWNERS and organization team membership change.

Proposal

Add an automated or clearly owned process for generating the ownership data used by the issue triage workflow.

This has two related parts:

1. Deterministically read and update CODEOWNERS-derived routing data.

   • Parse CODEOWNERS using the same bottom-to-top, first-match-wins semantics the workflow expects.
   • Preserve the mapping from # Area-* section headings to owner entries.
   • Generate data or prompt content that can be reviewed in PRs rather than relying on manual transcription.
   • Decide whether CODEOWNERS-derived data should stay embedded in the workflow prompt or move to a generated data file consumed by the workflow.

2. Expand GitHub teams into individual assignment candidates using an organization-read token.

   • Use a token with enough organization read access to enumerate dotnet team members, including inherited child-team membership.
   • Decide whether this can be added to the existing Copilot PAT pool/token flow or should use a separate PAT/secret dedicated to team expansion.
   • Document the rotation and ownership expectations for whichever token is used.
   • Make the refresh process repeatable without manual ad hoc team expansion.

The process should answer:

• How often the snapshot should be refreshed.
• Which token, PAT, or GitHub App identity should be used to read organization team membership.
• Whether the refresh should run on a schedule, on demand, or as part of a workflow-generation step.
• How generated changes should be reviewed before they affect issue assignment.
• Whether generated ownership data should remain embedded in the workflow prompt or move to a generated data file consumed by the prompt/workflow.

Acceptance Criteria

• The CODEOWNERS parsing/update process is deterministic and documented.
• The team membership refresh process is documented and assigned to an owner.
• The token choice is documented, including whether the existing Copilot PAT path can be reused or whether a separate org-read PAT/secret is required.
• The process avoids requiring manual ad hoc CODEOWNERS transcription or team expansion during normal workflow maintenance.
• The refresh path handles inherited child-team membership, matching the current snapshot behavior.
• The agentic triage workflow can be regenerated and compiled after the snapshot is refreshed.
• If automation is not immediately possible, a tracked manual cadence and owner are documented as an interim step.