Update mgmt scaffolding template and automation to emit CI trigger settings

Follow-up to Azure/azure-sdk-tools#16965.

## Summary

Azure/azure-sdk-for-net#62806 adds `trigger` blocks to the 246 existing `ci.mgmt.yml` files, but leaves the scaffolding path untouched. Without the changes below, newly onboarded management packages will not get a working trigger, and some of the applied changes can be silently reverted by automation.

Everything here lives in `azure-sdk-for-net`:

- `eng/templates/Azure.ResourceManager.Template/content/ci.mgmt.yml`
- `eng/scripts/automation/GenerateAndBuildLib.ps1`

## 1. Add the trigger block to the scaffolding template

`content/ci.mgmt.yml` is still `trigger: none`, so every newly scaffolded service starts with a disabled pipeline and re-introduces the exact gap #16965 describes.

The template should carry:

```yaml
trigger:
branches:
include:
- main
- hotfix/*
- release/*
paths:
include:
- sdk/LowercaseProviderShortName/Azure.ResourceManager.Template
```

**Good news: no substitution changes are needed for this.** Both consumers already replace these tokens, so the placeholder path resolves correctly:

- `.template.config/template.json` — `sourceName` is `Azure.ResourceManager.Template` and `LowercaseProviderShortName` is a derived symbol with `"replaces": "LowercaseProviderShortName"`.
- `GenerateAndBuildLib.ps1` → `Read-MgmtTemplate` — replaces `Azure.ResourceManager.Template`, then `AzureManagementTemplateSafeName`, then `LowercaseProviderShortName`, in that order.

Verified by simulating the `Read-MgmtTemplate` replacement chain, which yields:

```yaml
paths:
include:
- sdk/widgetfactory/Azure.ResourceManager.WidgetFactory
```

So this item is effectively a template-only edit.

## 2. `Update-CIYmlFile` must also add a trigger path (most important)

`Update-CIYmlFile` in `GenerateAndBuildLib.ps1` runs when a package is added to an **existing** `ci.mgmt.yml`. It appends to the `Artifacts:` block only:

```powershell
$fileContent[$startNum - 1] += ([Environment]::NewLine + " - " + "name: $artifact" + [Environment]::NewLine + " safeName: $safeName")
```

It never touches `trigger.paths.include`. Once #62806 merges, that means a newly added package is **built by the pipeline but does not trigger it** — changes to it would queue nothing.

This is the same class of bug already found and fixed manually in #62806, where roughly 60 `Azure.Provisioning.*` artifacts were built by `ci.mgmt.yml` but missing from the path filters. Fixing the script is what stops it from recurring.

`Update-CIYmlFile` should insert a matching ` - sdk//` entry under `paths.include`, and should be idempotent in the same way the existing `name *: $artifact` guard is.

## 3. `RegisterMgmtSDKToMgmtCoreClient` rewrites `sdk/resourcemanager/ci.mgmt.yml` from hardcoded values

The same file contains:

```powershell
$newLines.Add(" include:") | Out-Null
$newLines.Add(" - sdk/resourcemanager") | Out-Null
$newLines.Add(" - common/ManagementTestShared") | Out-Null
$newLines.Add(" - common/ManagementCoreShared") | Out-Null
```

This regenerates the entire `paths:` block, which has two consequences:

- **It reverts manual edits.** #62806 narrows the entry to `sdk/resourcemanager/Azure.ResourceManager`; the next run of this function restores the broader `sdk/resourcemanager`. This function is worth checking before deciding whether that narrowing should stand at all.
- **It re-emits a stale path.** `common/ManagementCoreShared` does not exist in the repo (only `common/ManagementTestShared` does), so the nonexistent entry currently in `sdk/resourcemanager/ci.mgmt.yml` is reproduced by design rather than being a one-off mistake. It should be dropped.

## Acceptance criteria

- [ ] Scaffolding a new management service produces a `ci.mgmt.yml` with an enabled, correctly path-scoped trigger.
- [ ] Adding a package to an existing `ci.mgmt.yml` adds both the artifact **and** its trigger path.
- [ ] `RegisterMgmtSDKToMgmtCoreClient` no longer reverts intended `sdk/resourcemanager/ci.mgmt.yml` path filters, and no longer emits `common/ManagementCoreShared`.
- [ ] Every artifact in every `ci.mgmt.yml` is covered by a `trigger.paths.include` entry, with no extra or nonexistent paths.

## Validation note

When validating paths, compare against the git index rather than the filesystem. Azure Pipelines path filters are case-sensitive, but `Test-Path` on Windows is not — that gap hid a real casing bug in #62806, where `sdk/redhatopenshift` declares the artifact `Azure.ResourceManager.RedHatOpenshift` while the directory is `Azure.ResourceManager.RedHatOpenShift`. Deriving a path from the artifact name alone reproduces the typo.