Ignore empty object-stream messages in buffered byte receives - #1409

NOTE Erasing or replacing the contents of this template will result in your pull
request being summarily closed without consideration!

Changes

No linked issue.

BufferedByteReceiveStream.receive() currently returns b"" when a wrapped
ObjectReceiveStream[bytes] supplies an empty message. Empty messages are valid
objects, but ByteReceiveStream.receive() documents that implementations should
not return empty bytes. For example, a memory object stream containing b""
followed by b"abcd" makes receive(2) return b"" instead of b"ab".
Empty messages followed by sender closure likewise produce empty reads before EOF.

Skip empty object-stream messages until data arrives or the underlying stream
raises EndOfStream. Preserve the existing byte-stream path, maximum read size,
and buffering of surplus data. BufferedByteStream inherits the same fix.

The two regression tests use real memory object streams and both wrappers. They
cover consecutive empty messages, empties between data chunks, surplus buffering,
and empty messages followed by EOF. All 16 parametrized cases failed on the
unchanged implementation: either b"" != b"ab" or a missing EndOfStream.

Local validation on macOS, CPython 3.12.11, with asyncio, uvloop, eager asyncio,
and Trio (including the configured Blockbuster instrumentation):

• python -m pytest tests/streams/ -q --tb=short: 404 passed.
• python -m pytest tests/test_to_process.py tests/test_subprocesses.py -q --tb=short:
  137 passed, 3 skipped (uvloop does not support the tested user/group/umask options).
• pre-commit run --all-files: passed, including Ruff and mypy.

The full repository test suite, other Python versions, and Windows/Linux were
not run locally. This contribution was implemented and validated with OpenAI
Codex; no human review is claimed. Open PRs were checked for overlapping work.

Checklist

If this is a user-facing code change, like a bugfix or a new feature, please ensure that
you've fulfilled the following conditions (where applicable):

• You've added tests (in tests/) which would fail without your patch
• You've updated the documentation (in docs/), in case of behavior changes or new
  features
• You've added a changelog fragment (in changelog.d/).

The existing byte-stream contract is unchanged; the class docstring now documents
empty-message handling. No file under docs/ was changed. The changelog fragment is
changelog.d/1409.fixed.rst.

If this is a trivial change, like a typo fix or a code reformatting, then you can ignore
these instructions.

Updating the changelog

Add a news fragment file in the changelog.d/ directory, named
<issue or PR number>.<type>.rst, where <type> is one of:

• breaking: backwards incompatible changes
• added: new features
• changed: other user-visible changes
• fixed: bug fixes

If, say, your patch fixes issue #123, create changelog.d/123.fixed.rst
containing only a brief summary of the change, like this:

Fixed big bad boo-boo in task groups

The issue link and the credit for your pull request are added automatically on release.
If there's no issue linked, name the file after your pull request instead by adding the
fragment after you've created the PR.