skills: a duplicate skill name silently shadows the other, and the winner depends on walk order

## Gap

Skills are registered in a flat map keyed on the skill's declared name
(`src/opencode/skill/skill.ts:109`). When two skills share a name the second overwrites
the first, and the only signal is a `log.warn("duplicate skill name", …)` that no user
sees.

```ts
// Warn on duplicate skill names
if (skills[parsed.data.name]) {
log.warn("duplicate skill name", { name, existing, duplicate })
}
```

The warning names both locations, so the information exists — it just never reaches
anyone, and nothing decides *which* skill should win.

## Why this is reachable, not theoretical

Skill name uniqueness in the workspace is scoped **per creator**, not per tenant. Two
people in the same organisation can each own a skill called `deploy`, by design. The
skills a client syncs are the caller's own plus every organisation-visible one — so both
land in the same local snapshot, and the loader picks one arbitrarily.

Nobody sees a conflict. The author of the losing skill sees their skill "not working";
the winner sees nothing at all. Which one wins depends on filesystem walk order, so it
can differ between machines and between runs on the same machine.

This gets worse the moment publishing from the CLI exists (#1271), because sharing
skills is exactly what makes same-named skills common.

## Suggested direction

Needs a decision on precedence before a fix. Reasonable ordering: a project-local skill
should beat a synced one (you can always override what the workspace gave you), and
between two synced skills, something stable and explicit rather than walk order.

Whatever the rule, the collision should be visible — a duplicate name is a state the
user can fix, and today they are not told it exists.

Found while reviewing the workspace skill sync path.