chore(github): add CODEOWNERS field to RFC issue template

[krokoko]

Summary

• Adds an optional New CODEOWNERS file input field to .github/ISSUE_TEMPLATE/rfc.yml
• The field prompts RFC submitters to specify the GitHub team (e.g., @awslabs/agent-plugins-my-new-plugin) that will own the code for any new plugin or major component introduced by their proposal
• Field is not required — it applies only when the RFC introduces new code ownership boundaries

Motivation

The existing CODEOWNERS file and its associated instructions (.github/instructions/codeowners.instructions.md) establish strict rules for team ownership. By surfacing this requirement in the RFC template, owners can be identified early in the design process rather than at PR review time.

Build & Test Results

• mise run build — ✅ passed (lint, fmt:check, security scans all clean)
  • Markdown lint: 0 errors across 257 files
  • JSON manifest validation: all valid
  • Security scans (Bandit, Gitleaks, Checkov, Grype): all clean

Decisions

The new field is placed before the final admin metadata block (RFC PR / Approved by / Reviewed by), keeping it visible but clearly optional and out of the critical RFC content sections.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

Agent notes

What went well: The task was straightforward — the RFC template and CODEOWNERS file were easy to locate and understand. The codeowners instructions file gave clear context on what ownership entries should look like, which directly informed the placeholder text and description for the new field.

What was difficult: Nothing significant. The main judgment call was where to place the new field within the existing form structure.

Patterns discovered:

• This repo enforces strict CODEOWNERS formatting via .github/instructions/codeowners.instructions.md — any future plugin additions need that file updated following the 5-point checklist
• mise run build runs lint + fmt:check + security and is the single required validation gate
• The repo uses conventional commit format (<type>(<module>): description) as the PR title convention
• Git worktrees under .tmp/ are the preferred workflow for parallel work, but since this branch was already set up, direct commits were appropriate here

Suggestions for future tasks:

• When adding new plugins, the CODEOWNERS file needs updating alongside the plugin files — consider a lint rule or CI check that validates CODEOWNERS entries against the plugins directory
• The RFC template could eventually benefit from a checklist for the CODEOWNERS formatting rules to remind submitters of the vertical-alignment and alphabetical-sort requirements