fix(client create): honest conflict message — name the owner, handle cluster_in_use

[LukasWodka]

Summary

The CLI mapped every provisioning 409 to a single static message — "registered to a different tracebloc account — sign in to that account, or ask your admin" — which was frequently false (the same-account phantom case) and a dead end.

With the backend's fix#2 (backend#1021) the 409 body now distinguishes two cases, and this PR makes the CLI read them:

Backend 409 body	CLI message
cluster_conflict (+ owner_email)	"this cluster is already registered to another tracebloc account (owner@…) — ask them to release it, or sign in as that account"
cluster_in_use (+ holder_name)	"another tracebloc client (name) in your account is already live on this cluster — offboard it first with tracebloc delete, or provision on a separate machine"

This is the CLI companion to fix#2, and part of the phantom-client migration alongside cli#190 (fix#1).

Notes

• Names the owner so the user knows who to ask — no more dead-end "ask your admin". Guidance is contact-the-owner, never "delete the cluster" (it isn't ours to wipe), per the agreed UX.
• Degrades gracefully: against a backend withoutfixPhase 2: kubeconfig discovery + parent release detection + SA token #2 (empty/unparseable body), it falls back to the generic cross-account text — no hard dependency on deploy order.
• The client-side not-owned refusal (no HTTP body) keeps the generic message. crossAccountConflictMsg reworded to match ("another … ask its owner to release it").

Tests

owner_email surfaced + contact-the-owner guidance; cluster_in_use names the live client and must not read as cross-account; existing cross-account + client-side-refusal assertions updated to the new wording. Full go test ./... green; gofmt -s / errcheck / ineffassign / misspell clean.

---

Note

Low Risk
User-facing error text and JSON parsing only; no auth or provisioning flow changes beyond clearer 409 handling.

Overview
tracebloc client create no longer treats every provisioning 409 as a generic cross-account conflict. It parses the API error body and shows guidance that matches what the backend reports (fix#2).

For cluster_conflict, the message can include owner_email and tells the user to ask that owner to release the cluster or sign in as that account. For cluster_in_use, it names the live client (holder_name) and points to tracebloc delete or another machine—without implying another account. The same conflictMessage logic applies on PATCH anchor backfill 409s during R7 adopt.

If the body is missing or old, behavior falls back to updated generic cross-account copy (“another tracebloc account … ask its owner to release it”). Tests cover owner email, cluster_in_use, and updated wording.

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

[saadqbal]

Clean companion to fix #2 👍 Reading the structured error/owner_email/holder_name off the 409 body (rather than string-matching) is the right approach, both call sites are guarded (non-nil ae under the errors.As + Conflict check), and the degrade-to-generic fallback on an old/unparseable body means no deploy-order dependency. Client-side not-owned refusal correctly stays generic since it has no body to read.

Tiny cosmetic nit, non-blocking: when cluster_in_use comes back with an empty holder_name, the message reads "another tracebloc client (another of your clients) in your account…" — the doubled "another" is a little clumsy. Dropping the parenthetical when the name is unknown would read cleaner. Cosmetic only.