chore(release): bump to 0.10.20 so the staging hop can tag again (backend#2790)

[LukasWodka]

Why

v0.10.19 is already tagged, and both develop and staging read 0.10.19. So the staging hop has nothing to cut, and the one unshipped commit cannot ship.

Why a bump is required, not optional

The unshipped commit is the Dependabot pflag 1.0.9 → 1.0.10 bump (#575). It touches go.mod and go.sum — both inside this repo's declared publish_paths in release-train/repos.yml:

publish_paths: cmd/* internal/* go.mod go.sum VERSION scripts/install.sh scripts/install.ps1

So it changes a published artifact. I checked that against the declaration rather than assuming it — a dependency bump that only moved a test fixture would not have needed this.

Scope

One line. 0.10.19 appears nowhere else in the repo — verified by grep, not by expectation, since a version duplicated into a constant or a docs snippet is the usual way a bump half-lands.

Found during the pre-hop check for today's staging promotion: cli was the only version-gated repo with unshipped work whose version had not moved. client (1.9.92 vs 1.9.90) and design-system-v2 (0.2.1 vs 0.2.0) were both already correct.

Part of tracebloc/backend#2790.

---

Note

Low Risk
Only updates the VERSION file; no runtime, auth, or dependency changes in this diff.

Overview
Bumps the repo release marker in VERSION from 0.10.19 to 0.10.20 so the release train can cut a new tag.

This is a one-line version-only change (no application code in the diff). It unblocks staging promotion when v0.10.19 is already tagged and published paths still have commits that need a new release (e.g. the pending pflag dependency update described in the PR context).

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

[LukasWodka]

/fr-pass

Functional review on staging — passed, with direct evidence.

Journey (tier A), staging · amd64, run 33494337123 — green end to end, every leg:

install via the real installer → client components healthy → CLI installed from its signed release and signed in → dataset ingested for every task type → use case published → model trained and the leaderboard read.

The train leg, which is the one that matters:

experiment echi0zyk (pk 4041) started
experiment echi0zyk: COMPLETED (terminal, 29 poll(s))
inference submit: submitted for inference on cycle no 2
leaderboard: found after 6 poll(s), running_score=0.9, cycle=2
submissions: our run is on the board (accuracy=0.9 loss=0.3515 captured=True); 1 row(s) total

This repo's change is on the path that run exercised, so this is functional evidence rather than an inference from code review.

Two things stated rather than glossed:

• The run is against the deployed code. Backend f991c788 was helm upgraded into staging at 09:50:19Z and this journey started at 09:50:46Z. A separate journey (33493727497) sits red from 09:43:42 — seven minutes before that deploy — so it exercised the previous image and is not evidence about this promotion.
• e2e-test-agent did not ship this hop (blocked by a Bugbot High, e2e-test-agent#368). So this is yesterday's agent, and the run does not exercise e2e's own unshipped changes. It exercises the platform, which is what this card needs.