Linter: avoid single-word class names — must be descriptive

Parent: #4442

## Convention

**DO** Avoid using single-word class names. Use more descriptive names after consulting with the service development team. **DO NOT** duplicate names across different RPs.

> Source: [Azure SDK for .NET Mgmt Naming Conventions](https://github.com/Azure/azure-sdk-for-net/blob/main/doc/dev/Mgmt-Naming-Conventions.md)

## Observed today

A scan of `Azure/azure-rest-api-specs` (334 `client.tsp` files, 10,754 csharp-scoped `@@clientName` decorators) shows **585** decorators currently encoding this rule by hand. Examples:

- `Control` → `RecommendationControlType` (advisor/resource-manager/Microsoft.Advisor/Advisor/client.tsp)
- `Duration` → `AdvisorLowCpuEvaluationDuration` (advisor/resource-manager/Microsoft.Advisor/Advisor/client.tsp)
- `Category` → `RecommendationCategory` (advisor/resource-manager/Microsoft.Advisor/Advisor/client.tsp)
- `Impact` → `RecommendationBusinessImpact` (advisor/resource-manager/Microsoft.Advisor/Advisor/client.tsp)
- `Priority` → `RecommendationPriority` (advisor/resource-manager/Microsoft.Advisor/Advisor/client.tsp)
- `Reason` → `RecommendationStateChangeReason` (advisor/resource-manager/Microsoft.Advisor/Advisor/client.tsp)

## Proposed linter

**Detection**

Flag any exported model whose csharp name is a single PascalCase word matching one of a curated dictionary of generic terms (`Resource`, `Connector`, `Control`, `Category`, `Duration`, `Impact`, `Priority`, `Status`, `Type`, `Settings`, `Properties`, ...), OR which collides with a model from another RP (cross-spec check).

**Auto-fix**

Suggest a service-prefixed name via `@@clientName(..., "csharp")`. Cross-spec collision detection can run in a separate sweep.

**Scope**

The rule should be csharp-scoped — it only flags violations of the .NET convention, not the underlying TypeSpec name. It should suggest inserting a `@@clientName(..., "csharp")` override when the underlying TypeSpec name is intentional, or renaming the TypeSpec model when the convention applies cross-language.

## Acceptance criteria

- [ ] New lint rule registered in the appropriate ruleset (`@azure-tools/typespec-client-generator-core` or `@azure-tools/typespec-azure-resource-manager`).
- [ ] Doc page under `website/src/content/docs/docs/libraries/.../rules/`.
- [ ] Unit tests covering positive / negative cases and the auto-fix.
- [ ] A `.chronus/changes/` entry.

Start by inspecting existing lint rules in @azure-tools/typespec-client-generator-core and @azure-tools/typespec-azure-resource-manager, including how rules are registered and tested. Then review the documentation structure under website/src/content/docs/docs/libraries/.../rules/. Done means the rule, positive/negative and auto-fix tests, documentation page, and a .chronus/changes/ entry are present.

Written by the indexing model from the issue text.