feat: implement AI-powered smart router to assign team ownership to unplanned GitHub issues

Background

It is healthy and encouraged for contributors outside of defined team planning cycles to open PRs and issues — it's a sign of broad engagement and cross-team velocity. However, it creates a practical gap: these contributions arrive without a defined owner, which leads to missed QA and accountability issues if not addressed.

This issue proposes a lightweight routing solution to bridge that gap.

Problem

GitHub issues submitted by contributors outside of sprint planning end up unowned. Without a team assignment, they may go through merge and release without scheduled QA. The current ad-hoc ownership model is not sustainable.

Proposal

Build a routing workflow that:

1. Detects unplanned GitHub issues from contributors not belonging to a defined team
2. Analyzes content (title, description, labels, linked PRs) to determine the appropriate owning team
3. Applies a team label to the issue (labels are for issues only — PRs are not labeled with team tags)
4. Sends a Slack notification to the assigned team, letting them know a new issue has been routed to them

Role of dotcms-aios

dotcms-aios should serve as the source of truth for the context used to make routing decisions — team definitions, ownership pillars, domain boundaries, etc. The routing logic itself may live elsewhere (e.g. a GitHub Action or a separate agent), but it should consume context from dotcms-aios.

Example ownership mappings:

• UVE-related → Scout
• Analytics-related → Falcon
• Auth, sessions, cache/Redis → Platform
• FE-only → available FE bandwidth (e.g. support rotation)

Acceptance Criteria

• Team ownership mappings and domain context are documented in dotcms-aios
• A routing agent analyzes an issue and outputs a team assignment with reasoning
• The correct team label is applied to the issue (issues only, not PRs)
• A Slack notification is sent to the assigned team channel when an issue is routed to them
• Routing decisions are explainable — the agent states why it picked a team
• Issues outside all team scopes (experimental, infra-only, etc.) are flagged separately rather than forced into a team

Start by reading the team definitions, ownership pillars, and domain boundaries in dotcms-aios, then trace how unplanned GitHub issues could be detected and routed. Done means an explainable team assignment, the correct issue-only label, a Slack notification, and separate handling for issues outside team scopes.