[ar-api] Upload native Action Recognition videos (VID-35)

[digaobarbosa]

Description

Action Recognition users can create and train projects through the SDK, but could not upload a native video for annotation. Existing video calls extract frames or run inference rather than creating a video Source in a dataset.

Project.upload_video("clip.mp4") now streams the original bytes through the platform's signed upload flow and returns processing status. Callers can poll or use a bounded wait, then use the final videoId as the Source ID. Ingestion may deduplicate onto an existing Source. The call forwards the API's batch, tags, metadata, and split options; image uploads and their retry behavior are unchanged.

Validation

• Local: python -m unittest tests.test_native_video_upload tests.test_project — 42 passed, including public SDK calls against loopback HTTP for original-byte PUT, canonical status, delayed status timeout, transport errors, and existing image uploads. Ruff format/check, mypy on changed modules, and git diff --check passed.
• Staging SDK E2E on exact head 4933744cff7ad99e298c46dc26f089d515b59a00, 2026-10-02 11:25:20–11:25:43 UTC, model-evaluation-workspace via api.roboflow.one: an owned private Action Recognition project uploaded a 24,523-byte MP4 with wait=True and a 37,771-byte MOV with wait=False, explicit get_video_upload_status, then bounded wait_for_video_upload. Both preparation requests and signed GCS PUTs returned HTTP 200; the observer confirmed complete fixture stream consumption. Both reached uploaded and resolved to batch 7mwvVebZ3zfsReTf0jon.
• MP4 returned canonical Source g5uxMmLMPEbRkVmMHl4P. Public Project.image read both Sources as mediaType=video; MP4 tag, metadata and split=train were read back. Public annotation batches reported mediaType=video for the task batch. Reuploading the owned MP4 sent its full bytes again, then returned duplicate:true, the original canonical Source ID, and resolvedBatch:null.
• Browser DOM on the owned unassigned annotation batch showed 2 Videos: vid44-native-mp4 and vid44-native.mov, each 0:02. Playback and annotation were not exercised. Dataset /videos browse was empty because these Sources were not annotated into the dataset.
• Cleanup: the exact owned project was deleted through public SDK Trash, restored only for that UI check, then deleted again. Final DELETE returned HTTP 200; active GET returned 404 and Trash contained exact project ID yckFzKF1RHup4Tmy24FU. No shared Source or GCS object was deleted; task-only files were removed.

Sanitized SDK call shape (supply the key privately as $STAGING_API_KEY):

rf = Roboflow(api_key=os.environ["STAGING_API_KEY"])
project = rf.workspace("model-evaluation-workspace").project(owned_project)
mp4_status = project.upload_video(mp4_path, batch_name=batch, tag_names=[tag], metadata=metadata, split="train", wait=True)
mov_status = project.upload_video(mov_path, batch_name=batch, wait=False)
project.get_video_upload_status(mov_status["videoId"])
final_mov_status = project.wait_for_video_upload(mov_status["videoId"])

Platform contract and runtime limit

The direct upload API prepares a signed URL and required headers, then reports pending, uploaded or failed status with the canonical Source ID after ingestion. This PR changes only the native video SDK upload path; image upload retries and segment annotation are outside its scope.

Staging upload, finalization and public Source readback are verified at this exact SDK head. Production/EU deployment, playback, segment annotation, and stored GCS byte hashing were not tested. Requests timeouts limit connection/read inactivity, not the total wall time of a slowly streaming response; poll_timeout=0 makes one status request with the default transport timeout. This PR does not deploy the platform route or publish a package.

[joaomarcoscrs]

LGTM