fix: preserve memoryview bytes in sandbox streaming uploads

[Kayvan-Zahiri]

The sync and async sandbox files.upload_stream helpers treat a memoryview as an iterable of chunks. Iterating a view yields integers, and bytes(integer) creates that many NUL bytes rather than encoding the original byte. For example, a view of b"abc" produces 294 NUL bytes rather than three bytes of file data. This also mishandles sliced, non-contiguous, and wider-element views.

Handle memoryview alongside bytes and bytearray before the iterable branch. Converting the whole view to bytes preserves its selected data and does not release the caller’s view. Document the supported bytes-like input on both public upload methods; existing readable-file and chunk-iterator paths stay unchanged.

Eighteen public-method regression/control cases consume the actual generated upload stream through recording runtime transports. They cover ordinary, sliced, strided, wide-element, and empty views, plus bytes, bytearray, file, and chunk-iterator controls, across sync and async APIs. Before:8 failed,10 passed. After:18 passed. The full non-E2E suite reports1017 passed,4 skipped,1 failed. The sole failure, test_fingerprint_format_is_stable_across_python_versions, also fails on the original unmodified source in this macOS/Python3.12 environment; no fingerprint code was changed. Repository-wide Ruff lint, changed-file Ruff format, and git diff --check pass. No cloud sandbox or browser was launched.

Developed with Codex assistance; reproduced and verified locally.