Add an app-binary-path input for uploading a fresh build

[Romaaan3]

Summary

• Mobile runs can now set app-binary-path: an .apk, .aab or .ipa in the workspace. The action uploads it to the product and starts the session on that binary, so CI tests the build it just made instead of whatever an app-binary-id points at.
• The upload is the API's two-phase direct upload: initiate_upload, then a PUT of the bytes to the returned URL carrying only the returned headers (the API key never reaches the storage host), then commit_upload. The binary id it returns goes out as selected_artifact_id.
• It is one more app source, so it cannot be combined with app-binary-id, app-package or mobile-browser. The file and its extension are checked before anything is created.
• Uploading needs an owner or engineer token; both upload endpoints refuse every other role.

Docs

The README gained a "Fresh builds" section on where the file comes from (a build job via artifacts, the same job, or a download) and a two-job Android example built with assembleDebug, with a note that assembleRelease only writes an installable app-release.apk when release signing is configured. The owner-only wording for listing and uploading binaries now says owner or engineer, which is what the API enforces.