Write down why companion declarations are copied between instances, not shared

> ⚠️ **Filed by Claude (AI assistant) on jmchilton's behalf** — written by Claude, not authored by them personally.

Split out of #15 (question 6), where the decision was taken: **keep duplicating.** This issue is the "write it down" half.

## The situation

Three kind declarations now name the same companions:

| | `eval.md` | `scenarios.md` | others |
|---|---|---|---|
| GWF `mold` | rec · foundry-only | rec · foundry-only | 7 more |
| GWF `pipeline` | rec · foundry-only | rec · foundry-only | `examples/`, `README.md` |
| SGF `mold` | rec · foundry-only | rec · foundry-only | — |

`pipeline`'s four are a strict subset of `mold`'s nine, identical on both axes. By the ordinary rule — two callers is coincidence, three is a pattern — this is where a shared constant would go.

## Why it does not go there

**The third caller is in another repo.** A constant shared inside `galaxyproject/foundry` covers two of the three; SGF would still declare its own.

**A substrate-level set would destroy the evidence it looks like it captures.** The Kind Catalog's strongest claim is that two independently-motivated foundries put the same two files beside a Mold, at the same requirement and the same disposition. Ship that set as a constant in `@galaxy-foundry/kind-schema` and the agreement becomes an artifact of the import — the page would be reporting that both instances read the same file. SGF's own `mold/schema.ts` says as much: *"That the same two filenames arrived independently in both Foundries is the substrate claim the kind catalog can now make: a companion transferring is stronger evidence than a kind NAME transferring."*

**Honest qualification, and it belongs in the writeup.** The *files* converged independently — SGF carries them beside 13/13 molds from practice. The *declaration prose* did not: the `purpose` strings are byte-identical across the repos, transcribed from GWF. The transfer evidence is real at the layout level and not at the prose level. galaxyproject/foundry-pattern#18's tests pin file, requirement and disposition, and deliberately never `purpose`.

## The work

Record the rule where a new instance would actually look — the Kind Catalog page or `standing-up-a-foundry`, not a closed issue. It should say: **copy the companion declarations, do not import them**, and say why, so the repetition reads as deliberate rather than as an abstraction nobody got round to.

Worth stating the general form too, since it is the same reasoning #15 used for `prompt`: a substrate that prescribes layout stops being able to observe whether layout transfers.

Start with the Kind Catalog page or standing-up-a-foundry, the two locations named for the writeup. Document that companion declarations should be copied rather than imported, including the reasoning about independently observed layout and the limitation of transferred prose. Done means a new instance can find and understand this rule.

Written by the indexing model from the issue text.