Clarify Components code documentation guidance

[PureWeen]

Summary

• Prefer precise names, named methods or variables, and single-purpose responsibilities before adding implementation comments.
• Reserve comments for durable reasons that cannot be expressed through structure alone.
• Keep public XML documentation focused on consumer-observable behavior instead of internal implementation details.

This follows the guidance discussed in #68114 (comment) and #68114 (comment).

Validation

Documentation-only change; git diff --check passes.

[Copilot]

Pull request overview

Updates the Components area contributor guidance to emphasize code clarity through structure (names, extracted methods, single-responsibility units) before adding implementation comments, and to keep public XML docs focused on consumer-observable behavior rather than internal mechanics.

Changes:

• Adds a new “Code clarity and durable knowledge” section encouraging structural clarity over narrative comments.
• Specifies when implementation comments are appropriate (durable, non-local reasons such as cross-boundary ordering or compatibility constraints).
• Clarifies that public XML documentation should avoid internal control-flow/lifecycle details and instead describe observable behavior.

Show a summary per file

File	Description
src/Components/AGENTS.md	Adds durable guidance on preferring structural clarity over comments and constrains public XML docs to consumer-facing behavior.

Review details

Tip

Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Lite