Linter: avoid `Microsoft`/`Azure` prefix on model / class names

Parent: #4442

## Convention

Avoid using `Microsoft`, `Azure` prefixes for any models or classes.

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

- `AzureFunctionDefinition` → `InternalAzureFunctionDefinition` (ai/Azure.AI.Agents/client.tsp)
- `AzureBlobContentSource` → `BlobContentSource` (ai/DocumentIntelligence/client.tsp)
- `AzureBlobFileListContentSource` → `BlobFileListContentSource` (ai/DocumentIntelligence/client.tsp)
- `AzureApiManagementSource` → `ApiCenterApiManagementSource` (apicenter/ApiCenter.Management/client.tsp)
- `AzureMonitorExporter` → `ApplicationInsightsRestClient` (applicationinsights/data-plane/Exporters/client.tsp)
- `AzureLargeStorageInstance` → `LargeStorageInstance` (azurelargeinstance/resource-manager/Microsoft.AzureLargeInstance/AzureLargeInstance/client.tsp)

## Proposed linter

**Detection**

Flag any model whose name starts with `Microsoft` or `Azure` (case-sensitive). Allow well-known service identity types via a `known-prefixed-types` allowlist.

**Auto-fix**

Suggest dropping the prefix via `@@clientName(..., "csharp")`.

**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 the existing lint rules and registration in @azure-tools/typespec-client-generator-core or @azure-tools/typespec-azure-resource-manager, then review related rule tests and autofix patterns. Add the csharp-scoped rule, allowlist, documentation under website/src/content/docs/docs/libraries/.../rules/, unit tests for positive, negative, and autofix cases, and a .chronus/changes/ entry.

Written by the indexing model from the issue text.