…ble (#720)

## Summary

Adds a new `reconnect: bool = True` kwarg to `DeepgramClient` and
`AsyncDeepgramClient`. When a custom `transport_factory` is provided,
`reconnect` is auto-set to `False` to signal that the custom transport
owns its own retry/reconnect lifecycle.

## Why

Custom transports (e.g., the SageMaker transport in
`deepgram-python-sdk-transport-sagemaker`) implement their own retry and
reconnect logic — full-jitter backoff, retry-budget windows, replay
buffers, etc. Stacking SDK-level retries on top of that would cause
storm-on-storm behavior under burst load, which is the failure mode that
motivated this parity work across the SDKs.

This adds an explicit, declarative way to express "the SDK is not
responsible for reconnects." Today the Python SDK has no wrapper
reconnect layer (the `websockets` library doesn't auto-reconnect;
transports manage their own), so the flag is **declarative only**: it
documents intent and reserves the slot for any future SDK-side reconnect
logic.

## Parity with other SDKs

- Mirrors the `reconnect` parity work in `deepgram-java-sdk`
- Same flag added to `deepgram-js-sdk` in PR #492
(`gh/pluggable-transport-sagemaker`)

## Behavior

```python
# Default — reconnect=True, no custom transport: SDK behaves as before
client = DeepgramClient(api_key="...")
assert client.reconnect is True

# Custom transport — reconnect auto-disabled to False
client = DeepgramClient(api_key="...", transport_factory=my_factory)
assert client.reconnect is False

# Explicit opt-in even with custom transport — caller takes responsibility
client = DeepgramClient(
    api_key="...",
    transport_factory=my_factory,
    reconnect=True,
)
assert client.reconnect is True
```

## Test plan

Covered in `tests/custom/test_transport.py`:

- [x] Default state: `client.reconnect == True`
- [x] Explicit `reconnect=False` is respected
- [x] `transport_factory` auto-disables → `reconnect == False`
- [x] Explicit override `transport_factory=..., reconnect=True` is
respected

## Release impact

- `feat:` → minor version bump per release-please conventions
- Fully backwards-compatible — new optional kwarg with sensible default;
existing callers need no change
- No regen impact: hand-written patch to `src/deepgram/client.py`,
already in `.fernignore`

🤖 I have created a release *beep* *boop*
---


##
[7.3.0](v7.2.0...v7.3.0)
(2026-06-01)


### Features

* **client:** add a declarative `reconnect` flag with transport-factory
auto-disable. `DeepgramClient` / `AsyncDeepgramClient` now accept
`reconnect: bool = True` (exposed read-only as `client.reconnect`). When
a custom `transport_factory` is supplied, `reconnect` auto-sets to
`False` to signal that the transport owns its own retry/reconnect
lifecycle — e.g. the SageMaker transport's jittered backoff + replay
buffers — so SDK-level retries don't stack on top and cause
storm-on-storm under burst load. Pass `reconnect=True` explicitly to opt
back in. Declarative only for now (the Python SDK has no wrapper
reconnect layer; `websockets` doesn't auto-reconnect), fully
backwards-compatible, and parity with the same flag in the JS
([#492](deepgram/deepgram-js-sdk#492)) and
Java SDKs
([#720](#720))
([b5d5905](b5d5905))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Greg Holmes <greg.holmes@deepgram.com>