bodies.md describes retry body-buffering by constructor total_retries, not the effective per-call total

[OmarAlJarrah]

Problem

docs/bodies.md describes when the retry policy buffers a single-use body purely in terms of the constructor argument total_retries: it says buffering happens "whenever total_retries > 0" and is "skipped when total_retries == 0". The actual code decides from the effective per-call total returned by _configure_settings(ctx.options), which merges any per-call retry_total override with the constructor default. So a per-call retry_total=3 over a total_retries=0 instance does buffer, and a per-call retry_total=0 over a total_retries=3 instance does not — the opposite of what bodies.md states. docs/pipelines.md already describes this correctly, so the two documents disagree.

Where

docs/bodies.md:19-26:

The retry policy in `pipeline.policies.retry` **does** automatically
buffer single-use bodies when retries are enabled: `RetryPolicy.send`
calls `body.to_replayable()` before the first attempt whenever
`total_retries > 0`. ... skipped when `total_retries == 0`

packages/dexpace-sdk-core/src/dexpace/sdk/core/pipeline/policies/retry.py:226-227:

settings = self._configure_settings(ctx.options)
if settings["total"] > 0 and request.body is not None and not request.body.is_replayable():
    request = request.with_body(request.body.to_replayable())

settings["total"] is the per-call effective value, not the constructor field.

Impact

A reader following bodies.md mis-predicts replay behaviour for the per-call override case: they may pass retry_total at call time and reason incorrectly about whether a from_stream / from_iter body will be buffered, leading to either an unexpected single-use RuntimeError or an unexpected in-memory buffering.

Suggested fix

Reword bodies.md to state that buffering fires when the effective per-call retry total is positive — i.e. the constructor default merged with any retry_total in ctx.options — matching pipelines.md and the code.

[WilliamK112]

I can take this too and include it in the same small docs PR as #48. I checked RetryPolicy.send(): it uses _configure_settings(ctx.options) and then the effective total setting for the buffering decision. Plan: reword docs/bodies.md to describe the effective per-call retry total, matching docs/pipelines.md and the code.