feat(cloud): add TestingBot real device cloud provider

[jochen-testingbot]

What

Adds TestingBot as a sixth cloud device farm, alongside BrowserStack, Sauce Labs, LambdaTest, AWS Device Farm and Firebase Test Lab.

Disclosure: I work at TestingBot. This is a vendor integration for our own platform, written against the public API — happy to adjust anything that doesn't fit how you'd like third-party providers handled here.

Why

TestingBot is a real device cloud in the same category as the three farms already supported, and CloudProvider is a clean extension point, so this slots in without disturbing existing providers.

How

internal/cloud/testingbot.go implements the existing CloudProvider interface. The only change to shared code is one case in NewProvider — nothing on the cloud path in internal/cli/test.go moves.

Method	Endpoint
UploadApp	POST /v1/storage (multipart file) → tb://<appkey> for appium:app
ListDevices	GET /v1/devices → name / platform_name / version
StartSession / StopSession	Appium W3C hub at hub.testingbot.com, credentials in tb:options
GetSessionArtifacts	GET /v1/tests/<id>/assets → video + screenshots

Endpoints and payload shapes were taken from the TestingBot OpenAPI spec (api.testingbot.com/v1/openapi.json) and the Appium support docs, not from memory.

Two decisions worth your review:

• Credential naming. Resolves key/secret (TestingBot's own naming, matching TESTINGBOT_KEY/TESTINGBOT_SECRET) and falls back to the generic username/access_key. That keeps --cloud-key/--cloud-secret and probe.yaml working without editing the shared credential map in test.go, which would have touched all five existing providers. Happy to flip to generic-only if you'd rather keep one convention.
• Relay mode only. ForwardPort passes through when RelayURL is set and otherwise returns an error pointing at --relay, exactly as Sauce Labs and LambdaTest do. Direct forwarding would need the TestingBot Tunnel binary; that can be a follow-up if it's wanted.

Artifact collection polls up to 30s because TestingBot processes assets asynchronously — same shape as the existing BrowserStack video poll.

Tests

internal/cloud/testingbot_test.go covers credential resolution (both naming schemes and the failure cases), upload, device listing, capability construction for Android and iOS, the WebDriver error path, relay/direct ForwardPort, artifact polling, and session teardown.

To test against httptest I made the base and hub URLs struct fields defaulting to the package constants. The other providers hardcode consts and currently have no tests; I kept that change inside testingbot.go rather than refactoring them.

• make test — all 17 packages pass
• go build ./... and go vet clean; gofmt clean on the added files (firebase.go and lambdatest.go are gofmt-dirty on main already; left alone to keep this focused)

Not exercised against a live TestingBot account in this branch: request/response shapes are spec-verified, not wire-verified.

Also updated

README provider table, probe.yaml.example, the --cloud-provider flag help, the cloud.provider config comment, and the VS Code extension (setting enum, positional enumDescriptions, run-profile dropdown, extension README setup section).

No CHANGELOG entry — happy to add one under [Unreleased] in whatever wording you prefer if that's part of your flow.

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[jochen-testingbot]

I have read the CLA Document and I hereby sign the CLA