[FEATURE REQ] Expose stringEncoding on the convenience analyze overloads, Azure.AI.ContentUnderstanding (.NET, preview)

[Downloading (Gabegi)]

Technical Feedback

The REST operation /contentunderstanding/analyzers/{analyzerId}:analyze accepts a
stringEncoding query parameter to select the unit for span offsets (utf8 bytes,
utf16 code units, code points). In the .NET client this parameter is only reachable
through the protocol overload, which returns Operation<BinaryData>. The
convenience overload returns the typed AnalyzeResult but offers no way to set
the encoding, so callers get the service default.

Since C# string indexing uses utf16 code units, consumers of the typed API get
offsets on a different ruler and Substring(offset, length) misindexes any
content after the first non BMP character (emoji, CJK extensions, math symbols).
The mismatch is silent: nothing throws, spans just drift. This corrupts any
span based chunking or markdown slicing pipeline built on the typed models.

Desired Outcome

stringEncoding (or an equivalent enum) available on the typed analyze overload
or its options type, ideally defaulting to utf16 for .NET so typed results index
correctly into C# strings.

Current Workaround

A custom HttpPipelinePolicy registered via ClientOptions.AddPolicy(..., HttpPipelinePosition.PerCall) that appends stringEncoding=utf16 to :analyze
requests. It works because both overloads share the pipeline, but it is fragile
and undiscoverable.