Publish a self-documenting kind catalog in every Foundry

Start by reading the committed kinds.generated.json manifest and the existing loadKindDocs helper in foundry-lib, then review the KindCatalog.astro and KindReference.astro ownership described here. Done means every manifest kind has a local index and detail route, validated examples are shown as source, and the listed gallery, built-route, visual, and link checks pass across adopting Foundries.

Goal

Make every Foundry self-documenting by publishing a local kind catalog from its own committed kinds.generated.json.

The current cross-instance catalog is valuable comparison evidence, but it has to explain several Foundries at once. A local catalog should answer a different question: what does this kind mean in this Foundry?

Reader surface

Each Foundry should expose:

• /kinds/ — a compact inventory grouped by declared layer;
• /kinds/<kind>/ — a deep-linkable reference page for one kind.

The index should remain dense reference data: title, identifier, summary, shape, locations, field counts, companions, and links into the live corpus.

A detail page should render:

• definition, layer, shape, and content location;
• a locally derived browse link and note count;
• required and optional metadata tables;
• the directory/companion contract, including open-set semantics;
• the schema-validated example.md as escaped source;
• the rendered kind.md rationale;
• manifest source/provenance.

Ownership boundary

Concern	Owner
Manifest wire format	@galaxy-foundry/kind-manifest
Loading kind.md and example.md	@galaxy-foundry/kind-schema/docs
Catalog index/detail components	@galaxy-foundry/site-kit
Routes, corpus counts, collection links, Markdown rendering, theme	Each Foundry
Cross-instance comparison	foundry-pattern

The local pages must consume the generated manifest rather than introduce a second kind registry. Corpus counts and site URLs do not belong in the manifest. Examples render as source rather than as fake live notes.

No manifest format change is required: the current format already carries doc, example, locations, fields, shape, and companions.

Rollout

1. foundry-lib

• Add a shared loadKindExamples beside loadKindDocs.
• Add reusable KindCatalog.astro and KindReference.astro site-kit components.
• Export resolved presentation prop types; routes and corpus discovery remain instance-owned.
• Add role-based catalog theme tokens and style-gap checks.
• Add shared specimens for flat/directory kinds, required/optional fields, closed/open companion sets, long schemas, and present/absent examples.
• Extend the upstream minimum/designed gallery proof and publish a release.

2. bio-topo-foundry

Use as the first adopter because all current kinds already publish docs and examples.

• Replace its local example loader with the shared helper.
• Add /kinds/ and /kinds/[kind].
• Derive corpus links/counts locally.
• Add gallery renderer coverage, navigation, search, and built-output checks.

3. Galaxy Workflow Foundry

Use as the complexity test.

• Emit its already-validated example.md files into the manifest.
• Adopt the routes/components.
• Prove dense field tables, many companions, multiple locations, and the open research companion set.
• Add gallery and built-output coverage.

4. Statistical Genomics Foundry

Use as the vocabulary-divergence test.

• Emit examples into the manifest and adopt the routes/components.
• Preserve the real distinction that its research reference kind spans several note kinds.
• Add gallery and built-output coverage.

5. foundry-pattern capstone

Once canonical local URLs exist:

• keep the pattern page as the cross-instance comparison surface;
• simplify it toward a compact matrix;
• retain missing-kind, shape, required-field, and companion-layout comparisons;
• link each instance/kind cell to the canonical local detail page;
• add local kind-catalog acceptance to the standing-up checklist.

Acceptance

• Every manifest kind has exactly one local detail route.
• Every generated manifest includes kind.md and validated example.md content.
• No Foundry maintains a parallel kind-name array for this surface.
• Detail documentation is searchable; example source is excluded from search excerpts.
• Every new site-kit component is represented in the shared specimens and every adopting Foundry's component gallery.
• Dark/light and narrow/wide visual acceptance, style-gap checks, built-route checks, and link checks pass.

Relates to #13, which established per-kind directories and the cross-instance generated catalog.