Bug: auth login duplicate-target check compares workspace display name, not workspace ID

[zaynelt]

Summary

wk auth login rejects a legitimate new profile if another existing profile's introspected workspace happens to share the same display name, even when the two tokens belong to genuinely different workspaces (different numeric workspace IDs).

Where

internal/auth/profile.go:26 (hasDuplicateTarget):

if existing.Workspace == p.Workspace &&
    existing.Environment == p.Environment &&
    existing.Region == p.Region {
    return existing
}

Profile.Workspace is populated from info.Name (the human-readable name returned by GET /users/me), while Profile.WorkspaceID holds the actual numeric account ID (see internal/commands/auth.go:229-230). The duplicate check compares the display-name string instead of WorkspaceID.

Repro

1. Have two Workato trial workspaces both associated with the same account display name (e.g. "Zayne Turner") — this happens naturally when a user creates multiple trial/sandbox workspaces under one email.
2. Register the first as profile academy via wk auth login (env dev_sbx, region trial). Confirmed via GET /users/me this token's workspace ID is 2100005003.
3. Attempt to register a second, unrelated workspace (workspace ID 2100000735, confirmed via GET /users/me on that token) as a new profile:

wk auth login --token <token> --environment dev_sbx --region trial --name e2e-test --no-input --force

Actual

Error: saving profile: a profile already targets this workspace/environment/region combination: profile "academy" already targets Zayne Turner/dev_sbx (trial)

--force does not bypass this (per --help, --force only skips the overwrite confirmation for a same-named profile, not this cross-profile collision check) — so there's no workaround via flags. The only way to register the second profile is to fall back to a profiles.env file-store profile instead of wk auth login.

Expected

The duplicate-target check should compare WorkspaceID (or another stable identifier), not the mutable/collidable display name, so two distinct workspaces that happen to share a display name can both be registered.

Notes

• Pre-existing on develop (introduced in a4a1a53), not part of PR Zt/api gap closure #93 — found incidentally while smoke-testing Zt/api gap closure #93 against the dev-kit-testing project.
• Profile.WorkspaceID already exists and is populated at login time, so the fix is likely just swapping the comparison field in hasDuplicateTarget.