client create writes the numeric dashboard id (not the UUID username) as TRACEBLOC_CLIENT_ID → deployed client can't authenticate

[saadqbal]

Symptom

A freshly-provisioned client (tracebloc client create --credential-file ..., the RFC-0001 installer flow) deploys, but the jobs-manager pod crash-loops:

Authentication failed
Unable to log in with provided credentials

Found during v1.8.3 installer e2e on dev (client repo). The verify_credentials canary in install-client-helm.sh correctly rejected the same credential — it was masked by client PR #293 (skip-verify for minted creds), which will be reverted once this lands.

Root cause

internal/cli/client.go writes the credential as:

"TRACEBLOC_CLIENT_ID=" + strconv.Itoa(pc.ID)   // numeric dashboard id, e.g. "1052"

But TRACEBLOC_CLIENT_ID is the auth username, not a display id. The full chain:

cred TRACEBLOC_CLIENT_ID
  → install-client-helm.sh   TB_CLIENT_ID → values clientId
  → chart secrets.yaml       CLIENT_ID = clientId
  → jobs-manager pod env     CLIENT_ID
  → controller.py:545        username = os.getenv("CLIENT_ID")  →  POST api-token-auth {username, password}
  → backend                  authenticates EdgeDevice by its username

The backend's EdgeDevice.username is a UUID (str(uuid.uuid4()) in edge_device_serializer.create()), never the numeric id. So the pod sends username="1052", which matches no user → auth always fails. The password and everything else are correct.

Fix

Write pc.Username (the UUID) as TRACEBLOC_CLIENT_ID in both credential-file paths (mint + adopt) and in the printed-credential display (the numeric id is a dashboard reference only). Both existing credential-file tests asserted the buggy numeric id and are updated to require the username.

Acceptance criteria

• TRACEBLOC_CLIENT_ID in the written credential file == pc.Username (mint + adopt)
• Printed credential shows the username as "client id" (numeric shown as "dashboard id")
• Regression tests assert username, not id
• CLI patch release (v0.5.1) cut from main
• client PR #293 (skip-verify) reverted; installer e2e on dev goes green and the pod authenticates

Part of RFC-0001 (backend#830), installer credential handoff (#838).

[saadqbal]

✅ CLI fix shipped in v0.5.1 (main 0b01428, promoted via #124).

• cli#126 merged → develop → main; FR gate green.
• Tag v0.5.1 published: 8 cosign-signed binaries + SHA256SUMS + install.sh; releases/latest now resolves to v0.5.1, so the installer's install-cli.sh fetches the fixed binary.

Remaining acceptance criteria (leaving this open until done):

• client PR #295 (restore Step-5 verify canary, v1.8.4) — unblocked now, was gated on this
• installer e2e on dev: Step 5 verify passes and the pod authenticates (no crash-loop)