Design source canonicalization for multi-skill standalone repo adds

[christso]

Problem

Standalone skill URLs now install correctly, but adding multiple skills from the same repository can leave config in an ambiguous state.

Example starting point:

plugins:
  - source: https://github.com/NousResearch/hermes-agent/tree/main/skills/research/llm-wiki
    skills:
      - llm-wiki

If a later command adds another skill from the same repo, the system currently has no clear canonicalization strategy for whether the source should remain the deep skill URL or be promoted to a broader container path.

Goal

Define and implement canonical source promotion for repeated skill adds from the same repo, without expanding the config schema.

Desired behavior

When multiple skills are added from the same repo, rewrite the stored source to the smallest shared container that can express all enabled skills. For example:

• if all enabled skills are under skills/research/, promote to .../tree/main/skills/research
• otherwise, if all are under skills/, promote to .../tree/main/skills
• otherwise, promote to the smallest valid plugin/repo root needed

The resulting config should continue to use the existing model:

• plugins[].source
• plugins[].skills allowlist

Constraints

• Do not add new config fields if avoidable
• Preserve existing plugin and marketplace behavior
• Avoid duplicate plugin entries for the same GitHub repo identity
• Keep skill add, skill remove, skill list, and sync behavior coherent after promotion

Areas to inspect

• src/cli/commands/plugin-skills.ts
• src/core/workspace-modify.ts
• src/core/skills.ts
• config dedupe / plugin identity logic

Suggested acceptance criteria

1. Starting from a deep standalone skill URL, adding a sibling skill from the same subtree rewrites source to the shared subtree path
2. Adding a skill from a different subtree in the same repo rewrites source to the next valid shared container
3. No duplicate plugin entries are created for the same repo identity
4. Existing follow-up operations continue to work after promotion
5. Add unit and E2E coverage for canonicalization/promotion cases

Context

PR #406 intentionally fixed standalone skill URL installation only. The canonicalization/promotion behavior was left for follow-up because it is a design change, not just a bug fix.