Linter: DateTime properties/parameters must end with `On`

Parent: #4442

## Convention

**DO** End property or parameter names of type `DateTime` with `On`. Active voice: `StartOn`, `EndOn`. Passive: `CreatedOn`, `EstablishedOn`.

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

- `publishedAt` → `PublishedOn` (advisor/resource-manager/Microsoft.Advisor/Advisor/client.tsp)
- `updatedAt` → `UpdatedOn` (advisor/resource-manager/Microsoft.Advisor/Advisor/client.tsp)
- `expirationTimeStamp` → `ExpireOn` (advisor/resource-manager/Microsoft.Advisor/Advisor/client.tsp)
- `updatedAt` → `UpdatedOn` (advisor/resource-manager/Microsoft.Advisor/Advisor/client.tsp)
- `createdDateTime` → `CreatedOn` (ai/DocumentIntelligence/client.tsp)
- `lastUpdatedDateTime` → `LastUpdatedOn` (ai/DocumentIntelligence/client.tsp)

## Proposed linter

**Detection**

Walk properties/parameters whose effective type is `utcDateTime` / `offsetDateTime` / `plainDate` (or aliases like `Azure.Core.Foundations.…`). Flag when csharp name does not end with `On`. Common offenders today end in `At`, `Time`, `Timestamp`, `Date`, `DateTime`.

**Auto-fix**

Auto-suggest the rename: e.g., `createdAt`/`creationTime`/`createdDateTime` → `CreatedOn`; `expirationTimeStamp` → `ExpireOn`; `lastModifiedTime` → `LastModifiedOn`.

**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 and ruleset registration in @azure-tools/typespec-client-generator-core or @azure-tools/typespec-azure-resource-manager. Then review the documented rules under website/src/content/docs/docs/libraries/.../rules/ and existing unit tests to cover detection, exclusions, and auto-fix behavior. Done includes the rule, documentation, positive and negative tests, auto-fix coverage, and a .chronus/changes/ entry.

Written by the indexing model from the issue text.