Incorrect ServiceName/DisplayName written to release CSVs for auto-generated packages (word-smashing)

## Summary

When new packages (especially management-plane) are generated and their metadata is updated, the friendly `ServiceName`/`DisplayName` written to the release metadata CSVs (`_data/releases/latest/-packages.csv`) is frequently incorrect. The value is auto-derived by flattening the last package-name segment and capitalizing only its first letter, rather than using a curated service display name. This produces "word-smashed" strings.

## Scope: uniform across all languages

This is **not** language-specific. The same mechanism and the same smashed values appear in every language. Fixes are in flight across all five SDK languages (Azure/azure-sdk):

| PR | Language | Rows corrected |
|---|---|---|
| [#10201](https://github.com/Azure/azure-sdk/pull/10201) | Python | 52 |
| [#10200](https://github.com/Azure/azure-sdk/pull/10200) | Java | 38 |
| [#10199](https://github.com/Azure/azure-sdk/pull/10199) | .NET (Provisioning) | 70 |
| [#10197](https://github.com/Azure/azure-sdk/pull/10197) | Go | 56 |
| [#10196](https://github.com/Azure/azure-sdk/pull/10196) (merged) | JavaScript | 54 |

Approximately 270 rows corrected across the five languages.

## Concrete examples (before -> after)

The derived value is written to both the `DisplayName` column and the `ServiceName` suffix (e.g. `Resource Management - `).

| Package (segment) | Generated (wrong) | Corrected |
|---|---|---|
| `agricultureplatform` | Agricultureplatform | Agriculture Platform |
| `alertprocessingrules` | Alertprocessingrules | Alert Processing Rules |
| `azurestackhcivm` | Azurestackhcivm | Azure Stack HCI VM |
| `apimanagement` | Apimanagement | API Management |
| `cosmosdb` | CosmosDB | Cosmos DB |
| `commvaultcontentstore` | Commvaultcontentstore | Commvault ContentStore |
| `redisenterprise` | Redisenterprise | Redis Enterprise |
| `databoxedge` (JS) | Databoxedge | Data Box Edge |

Two classes of defect are visible: (1) missing word separation (`Agricultureplatform`), and (2) correct values that require curated/acronym knowledge no space-insertion heuristic can produce (`HCI`, `VM`, `API`, `DB`, proper casing like `Commvault ContentStore`).

## Where the value comes from (analysis)

The metadata-update agent tool does **not** author the friendly service name. It propagates a value that was derived upstream. Traced through `Azure/azure-sdk-tools`:

```
TypeSpec spec + tspconfig (package-dir, service-dir)
-> Release plan / SDK details resolution (derives serviceName + packageDisplayName)
-> DevOps release work item (Custom.ServiceName / Custom.PackageDisplayName)
-> azsdk_package_update_metadata (MetadataUpdateTool.cs - pass-through)
-> repo-configured update-metadata script (writes _data/releases/latest/*.csv)
```

Verified in-repo facts:

1. `MetadataUpdateTool.cs` (`azsdk_package_update_metadata`) does not compute a friendly name. It resolves the language service, runs the SDK repo's configured `update-metadata` script, then any language-specific steps. It is a pass-through.
2. In the agent's own `PackageInfo`, `ServiceName` is literally the SDK service folder name: `Path.GetFileName(Path.GetDirectoryName(fullPath))`. This is identical across the Python, Go, Java, JavaScript, and .NET language services.
3. The friendly values that reach the CSV originate from the DevOps release work item fields `Custom.ServiceName` and `Custom.PackageDisplayName` (`DevOpsService.cs`), which are set from the release plan's resolved SDK details.
4. eng/common metadata helpers only lowercase/hyphenate for doc slugs (`ServiceLevelReadmeNameStyle`, `GetDocsMsService`); they do not title-case or split words.

Characterization of the derivation producing the bad string: the friendly name is reconstructed from the last package-name segment (first letter capitalized, remaining word boundaries lost), then prefixed with a service-category label (`Resource Management - `, `Provisioning - `). The cross-language PR evidence confirms this: the same smashed segment appears identically in every language for the same service. Any approach that reconstructs a display name from an already-flattened package name is unreliable by design.

## Boundary / what was not inspected

- The exact code that writes each `_data/releases/latest/-packages.csv` lives in the respective language repo and was not inspected here. The analysis traces the value's origin and propagation through `azure-sdk-tools`; the language-repo write step consumes that value.

## Impact

- Incorrect service metadata surfaces in release tracking and downstream consumers of the CSVs.
- Approximately 270 rows required manual correction across five languages, and regeneration reintroduces incorrect values for new packages.
- Recurring manual-PR cleanup burden.

## Additional context

- Affected CSV rows frequently carry a `Needs Review` status flag, i.e. the pipeline emits values it cannot vouch for.

## Historical context

This CSV service-name cleanup has previously been handled manually by individual engineers (historically Ronnie, and possibly Wes). There is no automated or owned process ensuring correct friendly service names, which is why the same corrections recur with each new package generation.

## Open questions for triage

- Which step should own the authoritative friendly `ServiceName`/`DisplayName`, and what is the source of truth?
- Should new-package metadata resolution reconcile against a curated service catalog (acronyms, proper product names)?
- What is the full current list of affected packages beyond those in the in-flight PRs?