skill publish: name-conflict message says "in this workspace" but the conflict is account-wide

[anandgupta42]

Summary

skill publish refuses a name that already exists for this account with:

You already have a skill named "team-greeting" in this workspace. It was published from somewhere else, so this machine cannot update it — rename this one, or edit it in the workspace.

The phrase "in this workspace" is wrong. Skill names are unique per creator, across the account (#1280: "Names are unique per creator, so a blind re-create answers 409"). The message is shown when the workspace the project is linked to has never held a skill by that name, so the user goes looking in the wrong place. Observed on 0.12.1 (tenant anandtest1) while testing #1280/#1313 end to end.

Reproduction

1. Project A, linked to workspace 11: author .opencode/skills/team-greeting/SKILL.md, altimate-code skill publish team-greeting → Published "team-greeting" … (workspace 11 lists it).
2. Fresh project B (never linked), altimate-code link → "Create a quick workspace" → workspace 14 (empty, no skills).
3. In B, author a different team-greeting skill and run altimate-code skill publish team-greeting.
4. Output is the message above. Workspace 14 has no skill named team-greeting; the owner is workspace 11.

Source: packages/opencode/src/altimate/workspace/skill-publish.ts:261-267 (SkillNameConflictError).

Why it matters

• The user is told to "edit it in the workspace", opens workspace 14, finds nothing, and cannot tell where the conflicting skill lives.
• The local ledger explains the real situation (the id for that name is not known on this machine, or belongs to another project); the message should say that and name the workspace that holds the skill when the API returns it, or say "in your account" when it does not.

Suggested fix

Reword to the actual scope, e.g. A skill named "team-greeting" already exists in your account (published from another project or machine), so this publish cannot update it. Rename this skill, or update the original from where it was published. If the 409 detail carries the owning workspace or skill id, include it.

[anandgupta42]

@sahrizvi assigning to you with the other workspace-pilot findings. Found while running the v0.12.0/v0.12.1 skill-publish flow end to end on 0.12.1; the repro in the body is exactly what was run, and the source line is named. Everything else in #1280/#1313 passed: create then update, attach to the workspace, pull into a second checkout with the skill used on a plain question, and every refusal (built-in, workspace-sent, non-UTF-8 file with the path named, symlinked root, unlinked project).