Generate bearer constructors for multi-tag root and leaf clients

[HavenDV]

Summary

--security-scheme Http:Header:Bearer correctly rewrites operation security requirements, but tag-based generated clients do not receive the documented bearer-token convenience constructors.

Apple's official App Store Connect specification reproduces this with AutoSDK CLI 0.32.0+7ef4ef90a870ea4c953794f8a83e6ecff4ce87a3:

autosdk generate openapi.json \
  --namespace AppStoreConnect \
  --clientClassName AppStoreConnectClient \
  --output Generated \
  --targetFramework net10.0 \
  --exclude-deprecated-operations \
  --security-scheme Http:Header:Bearer

Generated operations require:

Type = "Http"
SchemeId = "HttpBearer"
Location = "Header"
Name = "Bearer"

but neither AppStoreConnectClient nor leaf clients such as BuildsClient have a string apiKey/bearer-token constructor. They only expose the low-level List<EndPointAuthorization> overload. The README produced by autosdk init still emits new AppStoreConnectClient(apiKey), which does not compile because the first constructor argument is HttpClient?.

This contradicts the current --security-scheme contract documented in the tryAGI workspace: bearer/api-key overrides should generate the corresponding convenience constructor.

Expected behavior

• Generate bearer-token convenience constructors for both the aggregate root client and independently usable leaf/tag clients.
• Ensure child clients created through the aggregate root inherit the same authorization state.
• Make the autosdk init README example compile for the selected security scheme.
• Keep the low-level authorization-list constructors available.

Acceptance criteria

• Add a multi-tag OpenAPI fixture with a bearer security override.
• Compile new RootClient(token) and new TagClient(token).
• Runtime-smoke a root child operation and a directly constructed leaf operation, asserting Authorization: Bearer <token>.
• Add scaffold coverage so generated README authentication examples compile.