Company Compute validation inverted live: valid keys 400 (task-id guard), garbage keys 403→'valid' — switch the probe to /solves/whoami

[kateebonner]

Important

Problem

Live testing with a real credential (2026-07-20): the authorizer-probe validation is inverted against the deployed service. A valid key now gets HTTP 400 on the fake-task probe (aws-infra#186 added a task-id format guard after the trick was designed, so __validate__ never reaches the handler) → classified error, not saved. A garbage key gets HTTP 403 (HTTP API lambda-authorizer denials emit 403, not the assumed 401) → classified valid → saved and shown Connected. Every unit test passed because the stub service pinned the assumed semantics.

Approach

Delete the probe hack: validate against the now-deployed GET /solves/whoami (aws-infra#185/#188) — 200 with a submitter = valid (identity captured, lighting "Connected as " at connect time — the designed upgrade path), 401/403 = invalid, network/5xx = unreachable. One server-side change in the fork's connections module covers both the panel and the re-pointed setCloudKey command.

Scope

• In: the fork's Company Compute validate step + tests/fixtures; identity captured on connect.
• Out: the drift-diff rendering (already shipped, 159/S9 — Resilience: staleness, offline, expiry, submitter-drift diff #170); revalidate path reuses the same probe automatically.

---

Acceptance Criteria

1. Against a stub whoami: 200 {submitter} → connected with identity persisted in status; 403 and 401 → invalid (nothing saved); network failure/5xx → unreachable (nothing saved).
2. No request ever targets a fake task id; the whoami path is the only validation call.
3. Connected status renders "Connected as " immediately after key entry (identity from the validate response).
4. Existing suites green; fixtures updated to the real gateway semantics (403-on-denial), with a comment citing the live finding.

Source

Found live with the internal test key (maps to raghav-internal). aws-infra#186 (the guard), #185/#188 (whoami). Part of the #159 family — post-ship hotfix.