Linter: enforce `CheckNameAvailability` rename pattern

Parent: #4442

## Convention

Rename `CheckNameAvailability` operation to `Check[Resource]NameAvailability`; param/response models to `[Resource]NameAvailabilityXXX`; reason enum to `[Resource]NameUnavailableReason`.

> 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 **174** decorators currently encoding this rule by hand. Examples:

- `checkNameAvailability` → `CheckAppComplianceReportNameAvailability` (appcomplianceautomation/AppComplianceAutomation.Management/client.tsp)
- `checkNameAvailability` → `CheckAppComplianceReportNestedResourceNameAvailability` (appcomplianceautomation/AppComplianceAutomation.Management/client.tsp)
- `CheckNameAvailabilityReason` → `AppComplianceReportNameUnavailabilityReason` (appcomplianceautomation/AppComplianceAutomation.Management/client.tsp)
- `CheckNameAvailabilityRequest` → `AppComplianceReportNameAvailabilityContent` (appcomplianceautomation/AppComplianceAutomation.Management/client.tsp)
- `CheckNameAvailabilityResponse` → `AppComplianceReportNameAvailabilityResult` (appcomplianceautomation/AppComplianceAutomation.Management/client.tsp)
- `CheckNameAvailabilityParameters` → `AppConfigurationNameAvailabilityContent` (appconfiguration/resource-manager/Microsoft.AppConfiguration/AppConfiguration/client.tsp)

## Proposed linter

**Detection**

Find operations / models named `checkNameAvailability` / `CheckNameAvailabilityRequest` / `CheckNameAvailabilityResponse` / `CheckNameAvailabilityReason`. Flag when csharp client name is not the per-RP scoped variant (`CheckNameAvailability`, etc.).

**Auto-fix**

Insert all four `@@clientName(..., "csharp")` decorators using the RP / resource name as context.

**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 locating existing lint rules in @azure-tools/typespec-client-generator-core and @azure-tools/typespec-azure-resource-manager, then inspect their registration and test conventions. Done means the csharp-scoped rule and autofix are covered by positive, negative, and autofix tests, with a page under website/src/content/docs/docs/libraries/.../rules/ and a .chronus/changes/ entry.

Written by the indexing model from the issue text.