python: document output_buffer_limit's block-granularity behavior

[MukundaKatta]

Refs #1460.

The docstring for Decompressor::process in python/_brotli.c describes output_buffer_limit as an absolute cap:

The maximum size of the output buffer. If set, the output buffer will not grow once its size equal or exceeding that value.

In practice the check is only applied inside the BROTLI_DECODER_RESULT_NEEDS_MORE_OUTPUT branch of the decompression loop, so the returned output can exceed the requested limit by up to one decoder block. Repro on x86_64 from #1460:

limit	bytes returned
1	32752
1024	32752
32752	32752
32753	98272

Rewrite the docstring so it describes what the code actually does — a best-effort, block-granularity cap — instead of implying a byte-precise hard limit. This matches the existing test assertions in python/tests/decompressor_test.py, which check against MIN_OUTPUT_BUFFER_SIZE (32 KiB) rather than the caller-supplied limit.

Testing

• Docstring-only change. No runtime behaviour change.
• Existing python/tests/decompressor_test.py::test_decompress_with_limit and test_changing_limit already assert len(decompressed_chunk) <= MIN_OUTPUT_BUFFER_SIZE (32 KiB), consistent with the new docstring wording; they continue to pass.
• I intentionally left the test assertions as they are — per-block cap matches what the code does, and tightening the test to the caller-supplied limit would invert the behaviour the docstring now documents.

Out of scope

The issue also suggests considering whether output_buffer_limit should be enforced at byte granularity. That would be a behavioural change in the Buffer_Grow path (the unconditional initial Buffer_Grow() call allocates MIN_OUTPUT_BUFFER_SIZE bytes before the loop even sees the limit), and likely a separate discussion; this PR only aligns the documented contract with the shipped behaviour.