[C# Naming] Consume C# naming rules from azure-sdk-for-net instead of restating them #17371

Summary

azsdk-common-typespec-naming (#17121) cites the .NET naming docs but also restates the C# rules inline in csharp-naming.md and csharp-model-naming.md. That leaves two rule sets in two repos that will drift. Make azure-sdk-for-net the single source of the C# naming rules: link to them, and keep only the TypeSpec-specific guidance here.

The goal is one C# rule set shared by .NET code review, spec authoring, and the TypeSpec assessment. The canonical rules cover data-plane as well as management, so a future C# data-plane profile can link to them instead of starting another copy.

Why

• The copies have already diverged. csharp-naming.md L16 accepts At for DateTimeOffset, inherited from the old management review skill. The canonical rule is On, with At allowed only under sdk/ai. Spec-time review would pass a new CreatedAt that .NET review then flags, which is the late rework loop [Epic] C# ARM SDK readiness before spec merge #17269 is meant to remove.
• The source links will break. Both profiles cite .github/skills/azure-sdk-mgmt-pr-review/SKILL.md (L5), which Add repository-wide Azure SDK code review skill azure-sdk-for-net#62615 deletes.
• The pinned snapshot is stale. The "Additional context" links (L7) pin repository-rules.md to 8ce543a7, an older #62615 commit. The naming section has changed since; for example, the parameter-name consistency check was rescoped and no longer auto-flags.

Proposal

1. Treat azure-sdk-for-net as the source of the C# naming rules. Today that is the Naming — Review-Only section of the #62615 code-review skill. Link to it on main after #62615 merges, not to a commit SHA.
2. In both profiles, replace the restated rule tables with links to the canonical sections. Keep only the TypeSpec-specific guidance: target selection, language-scoped @@clientName, wire-name preservation, emitter-synthesized types, shipped-API compatibility, and apply/validate.
3. Before deleting anything, diff the tools copy against the canonical rules. Move any rule that exists only here into azure-sdk-for-net, or drop it on purpose. For example, the bool Is/Can/Has prefix rule is in Mgmt-Naming-Conventions.md and here, but #62615 only says booleans should read affirmatively.
4. Have the assessment integration (Integrate shared SDK naming guidance into TypeSpec assessment #17297) use the same source instead of adding a third copy.

Open question

The skill is synced into other repos (e.g. azure-rest-api-specs), so the linked rules aren't local. Confirm that the authoring and assessment agents can fetch them at runtime. If they can't, generate a synced copy from azure-sdk-for-net with a drift check rather than hand-maintaining one.

Acceptance criteria

• azure-sdk-tools defines no C# naming rules of its own; the profiles link to azure-sdk-for-net.
• No links to azure-sdk-mgmt-pr-review or to pinned PR-branch SHAs remain.
• The existing naming evals (007001–007014 and typespec-naming-handoffs) still pass.

Dependencies

• Blocked on Add repository-wide Azure SDK code review skill azure-sdk-for-net#62615 merging.
• Follow-up to Add shared TypeSpec naming skill for authoring #17121; part of Build language-specific SDK naming rules into the TypeSpec authoring skill #17120 and [Epic] C# ARM SDK readiness before spec merge #17269.

🤖 m-nash-copilot