Add captcha task-start and challenge-result events

[archandatta]

Summary

• add captcha_solve_started for task acceptance and captcha_challenge_result for the overall visible-challenge outcome
• share the normalized BrowserCaptchaType across captcha events, including the existing press_and_hold wire value
• add optional task_id correlation and challenge_id grouping, with challenge_id required on challenge results
• cover both new event-to-category mappings with regression tests

Contract

captcha_solve_started records that a solver accepted one task. It does not assert that the solve is still running when a consumer receives it: delivery is asynchronous, a start can arrive after its result, and either event can be missing.

When present, task_id correlates one start with its terminal captcha_solve_result. duration_ms on the task result remains the authoritative task timing.

challenge_id groups multiple tasks from one visible challenge, such as image-grid retries, without indicating task ordering or completion. captcha_challenge_result is emitted once for the overall challenge, requires that grouping key, and reports solved or abandoned. A solved challenge issued a response token; it does not prove that the surrounding site flow accepted the token or succeeded.

Existing captcha_solve_result behavior is unchanged apart from the optional grouping field and shared captcha-kind schema.

Rollout

This change defines the schema and generated image API types only. Mirror the two new event types and shared captcha taxonomy into the public API and SDKs before any producer begins publishing them; producer changes follow separately.

Testing

• go test -race $(go list ./... | grep -v /e2e$) — pass
• go build ./... — pass
• go vet ./... — pass
• OpenAPI down-conversion plus Go generation chain, followed by git diff --exit-code — clean
• headful and headless Docker CI reruns — blocked in the unchanged FFmpeg download step because the upstream latest checksum manifest no longer contains the pinned ffmpeg-n7.1 archive

---

Note

Medium Risk
Contract and generated-type changes affect telemetry consumers and future producers; correlation semantics are easy to misuse if mirrored incorrectly in SDKs.

Overview
Extends browser captcha telemetry with captcha_solve_started (solver accepted a task) and captcha_challenge_result (one terminal outcome per visible challenge: solved or abandoned). The OpenAPI spec and generated oapi types wire both into the known telemetry union and map them to the captcha category.

Introduces shared BrowserCaptchaType (including press_and_hold) and BrowserCaptchaChallengeID for grouping retries. captcha_solve_result now uses that shared type, may carry optional challenge_id, and documents that duration_ms is authoritative and task_id pairs with the matching start event when present—not arrival order.

Adds TestCaptchaCategories so captcha_solve_started and captcha_challenge_result resolve to the captcha category. Schema-only in this PR; producers are expected to adopt publishing separately.

^{Reviewed by Cursor Bugbot for commit 978faed. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Sayan-]

Wire format is additive and safe: the new types land in a taxonomy-only union and challenge_id is optional. Two things I'd still fix.

1. Build break downstream. This deletes BrowserCaptchaSolveResultEventDataCaptchaType and its constants, and renames the status constants from Success/Failure/Timeout/Abandoned to prefixed forms. kernel/kernel uses both in packages/metro-api/lib/capmonsterrelay/relay.go, line 332 for status and line 363 for normalizeCaptchaType's signature and returns. metro-api resolves that import through a replace onto the internal mirror, so it breaks on the next sync plus module bump rather than at merge. Worth a companion PR landed first.

The status rename also looks unintentional. oapi-codegen only dropped the prefix because nothing collided; removing the captcha-type enum changed the collision set.

2. captcha_challenge_result.status is solved/abandoned only, so a solver hard-failure and a dismissed widget are indistinguishable. Adding failure or timeout later means widening a shipped SDK enum, which is the thing the rest of this PR is careful to avoid.

Nits: data is optional on the event, so required challenge_id isn't enforced. duration_ms is optional here but required on the task result.