Revisit protocol and convenience surface separation for streaming APIs

[JoshLove-msft]

Context

The current streaming result name and shape were designed to unify the type used across protocol and convenience surfaces.

Concern

Using one type for both surfaces may be contributing to discoverability and API-shape compromises. We should revisit whether protocol and convenience APIs need to return the same type.

Option to consider

• Have the protocol surface return the standard ClientResult.
• Introduce an AsyncStreamingCollection<T> convenience type.
• Provide a static FromResult factory to create the convenience wrapper from the protocol result.

Goal

Determine whether separating protocol and convenience return types produces a clearer streaming API without making interoperation cumbersome.