Define deletion semantics for linked project skills

**Describe the bug**

Project skill discovery supports whole-skill links, but source deletion resolves the linked directory and recursively removes the target. The current API therefore lacks a clear contract for whether deleting a linked project skill removes the local link, rejects the operation, or deletes the shared target.

The same provenance question affects update and export behavior for linked skills.

---

**To Reproduce**

1. Add a project skill as a whole-directory link to a valid skill outside the project.
2. Discover it through the ACP source API.
3. Delete the discovered project skill.
4. Observe that deletion operates on the resolved target rather than an explicit project-local identity.

---

**Expected behavior**

Define safe, compatible semantics for linked project skills. The preferred user-facing behavior should preserve shared targets unless target deletion is explicitly part of the supported contract.

---

**Screenshots**

Not applicable.

---

**Please provide the following information**

- **OS & Arch:** Cross-platform filesystem behavior
- **Interface:** ACP source API
- **Version:** current `main`
- **Extensions enabled:** Skills
- **Provider & Model:** Not applicable

---

**Additional context**

The design should choose among:

- unlink only the project-local link or junction and preserve the target;
- reject deletion of linked skills; or
- intentionally delete linked targets with an explicit confirmation and ownership contract.

It should also state whether update and export remain supported for linked roots. The verification plan should cover direct links, linked ancestors, ordinary project/global deletion, concurrent replacement, Unix symlinks, and Windows junctions/reparse points.

Do not begin implementation until this issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).