Align retry safety for mutating connector operations across SDKs

## Description

Align the .NET Connector SDK's retry safety contract with the Node.js SDK behavior introduced in [Azure/Connectors-NodeJS-SDK PR #91](https://github.com/Azure/Connectors-NodeJS-SDK/pull/91).

At `main` commit `64577be0333864d8315c3b9792df7abb1da99212`, generated .NET clients build the standard Azure.Core `HttpPipeline` from `ConnectorClientOptions`. The Connector SDK does not distinguish safe methods from mutating methods before the standard retry policy runs. As a result, transient responses or transport failures can replay POST, PUT, PATCH, and DELETE connector operations unless callers globally disable or replace retry behavior.

The cross-language Connector SDK contract should be:

- Retry safe methods (`GET`, `HEAD`, `OPTIONS`, and `TRACE`) according to the configured retry policy.
- Do not automatically retry unsafe methods (`POST`, `PUT`, `PATCH`, and `DELETE`) by default because a connector can commit an operation before returning a transient response.
- Provide an explicit, language-idiomatic per-client opt-in for applying the configured retry policy to unsafe methods, equivalent to Node.js `retryUnsafeHttpMethods`.
- Preserve Azure.Core retry tuning and custom policy/transport support.

## Motivation

Connector operations include side-effecting actions such as sending messages and creating meetings, chats, channels, or files. Automatically replaying a completed action can duplicate customer-visible effects. This risk and the desired explicit opt-in are protocol-level concerns, not Node.js-specific behavior.

Consistent defaults across the .NET, Python, and Node.js Connector SDKs make client behavior predictable when customers move the same connector integration between languages.

## Acceptance criteria

- Add a `ConnectorClientOptions` setting with .NET-idiomatic naming for opting unsafe HTTP methods into retries.
- Safe methods retain the configured Azure.Core retry behavior by default.
- Unsafe methods make one attempt by default for both transient HTTP responses and ambiguous transport failures.
- Unsafe methods use the configured retry behavior when explicitly enabled.
- Add focused tests proving at least:
- a transient GET is retried;
- a transient POST is sent once by default;
- a transient POST is retried when explicitly enabled;
- PUT, PATCH, and DELETE follow the unsafe classification.
- Document the default and opt-in behavior in API documentation and release notes.
- Confirm whether implementation is confined to hand-written runtime/options code. Generated-client regeneration is not expected because generated constructors already accept and forward `ConnectorClientOptions`.

## Related work

- Node.js implementation: [Azure/Connectors-NodeJS-SDK PR #91](https://github.com/Azure/Connectors-NodeJS-SDK/pull/91)
- Python alignment: [Azure/connectors-python-sdk issue #85](https://github.com/Azure/connectors-python-sdk/issues/85)

Start with ConnectorClientOptions and the generated-client construction path that forwards it into Azure.Core HttpPipeline, then inspect the hand-written runtime/options code. Add focused coverage for transient GET, POST, PUT, PATCH, and DELETE behavior with and without opt-in, and update API documentation and release notes when the default and opt-in behavior are confirmed.

Written by the indexing model from the issue text.