Skills cite knowledge files their domain does not ship (cross-domain knowledge is unsupported)

Four skills cite `knowledge/testing-layers.md`, a file that lives in `domains/testing/knowledge/`. Domain `knowledge/` is copied **per domain**, so a skill only ever receives its own domain's knowledge. These citations cannot resolve for any consumer, on any operator.

The skills install fine and the reference dangles — nothing errors, the agent simply cannot open what the body points at.

## Affected

| Citing file | Domain | Ships when |
|---|---|---|
| `domains/coding/skills/coding-guidelines/repos/metamask-mobile.md` (3 sites) | `coding` | `--repo metamask-mobile` |
| `domains/pr-workflow/skills/pr-guidelines/repos/metamask-mobile.md` | `pr-workflow` | `--repo metamask-mobile` |
| `domains/pr-workflow/skills/pr-readiness-check/repos/metamask-mobile.md` | `pr-workflow` | `--repo metamask-mobile` |
| `domains/perps/skills/perps-review-pr/skill.md` | `perps` | always |

Five of the six sites are in `repos/metamask-mobile.md` overlays, which is plausibly why this went unnoticed — it only manifests on Mobile installs.

## The underlying question

Cross-domain knowledge isn't a supported concept today. `testing-layers.md` is genuinely useful to skills outside `testing` — the citations are reasonable, the delivery mechanism just doesn't exist. Options, roughly in increasing order of cost:

1. **Rewrite the citations to name-only** — "see the `testing-layers` knowledge file" — so they stop promising a resolvable path. Cheapest, no installer change, but the agent still has no copy to read unless the `testing` domain was also installed.
2. **Duplicate the file** into each citing domain's `knowledge/`. Resolves everywhere, at the cost of four copies drifting apart.
3. **Teach the installer cross-domain knowledge** — a citation like `testing:testing-layers.md`, resolved and copied at install time. Cleanest for authors, most work, and it needs a decision about whether pulling one domain's knowledge into another is desirable at all.

I'd lean (1) or (3) over (2); duplicating a file that four skills depend on staying consistent seems like the worst of the three. But which of these is right depends on whether cross-domain knowledge is something this repo wants to support, which is a maintainer call rather than mine.

## Guard already in place

`test/cli.test.mjs` now checks the corpus and fails on any **new** dangling citation. These six are listed in `KNOWN_UNRESOLVED` so the check could land green rather than red. A companion test fails if a listed citation starts resolving, so the list can only shrink — closing this issue means deleting entries from it.

Start with test/cli.test.mjs and the six affected skill files, then inspect how domain knowledge is copied during installation. Determine which cross-domain knowledge approach maintainers choose. Done means the citations resolve through the chosen mechanism, or are intentionally rewritten, and the corresponding KNOWN_UNRESOLVED entries are removed.

Written by the indexing model from the issue text.