Labels Get/Post/Update responses omit Name; List returns full Label (Studio loses casing)

Problem

Labels HTTP responses disagree on whether display Name is part of the contract.

Clients that round-trip Create/Get/Update therefore only see the lowercased NormalizedName. List (and any consumer of the entity shape) still sees the original casing.

Evidence (main / elsa-core)

• List leaks the entity: src/modules/Elsa.Labels/Endpoints/Labels/List/Models.cs (ICollection<Label> Items)
• Get/Post/Update DTOs omit Name:
  • …/Labels/Get/Models.cs + Get/Mappers.cs
  • …/Labels/Post/Models.cs + Post/Mappers.cs
  • …/Labels/Update/Models.cs + Update/Mappers.cs
• Entity still stores display casing via Label.Name setter → NormalizedName (src/modules/Elsa.Labels/Entities/Label.cs)

Downstream (elsa-studio) — workaround, not a separate product decision

Elsa.Studio.Labels edit page already compensates:

// src/modules/Elsa.Studio.Labels/UI/Pages/Label.razor.cs
Name = label.Name ?? label.NormalizedName,

Studio model expects Name (Elsa.Studio.Labels/Models/Label.cs); Get returns it null, so the UI falls back to lowercased NormalizedName and loses original casing on edit.

Why subtractive

One response DTO (include Name everywhere, stop returning the raw Label entity from List) removes the dual contract and the Studio fallback. No new feature surface.

Proposed direction

• Align Get/Create/Update response DTOs with List: always return Name (+ keep NormalizedName if useful).
• Prefer a shared Labels response model over ICollection<Label> on List (avoids leaking TenantId / entity shape).
• Optionally drop the Studio Name ?? NormalizedName fallback once the API is fixed.

Out of scope / already tracked

• Memory vs EF Page.TotalCount → #8170
• Shell FastEndpoints registration for Labels → #8188

Light milestone note for Crew Lead: Soft Backlog / tech-debt hygiene after 3.8.3 integrity; not a 3.9 Ready candidate unless Studio Labels UX is actively prioritized.