fix(schema): merge same-name types by union, not replace (#154)

[avrabe]

Summary

Closes #154. Bridge and overlay schemas that re-declared an artifact-type or link-type with the same name as a base schema silently lost the base's fields. The merge was a plain HashMap::insert — later wins, parent fields gone.

This is the silent-correctness bug behind every bridge schema that re-declares a type to add a single safety attribute. A real reproducer in this repo:

• `schemas/safety-case.yaml` declares `safety-goal` with fields `[claim, goal-type, asil, undeveloped]` + link-field `sub-goal-of`
• `schemas/iso-26262.yaml` re-declares `safety-goal` with field `[asil]`
• Loading `[common, safety-case, iso-26262]` previously gave a `safety-goal` with only `[asil]` — the GSN `claim`, `goal-type`, and `sub-goal-of` link-field were silently dropped

Every safety-case artifact in such a project then tripped "field not defined" diagnostics and the missing link-fields broke cardinality enforcement.

The fix

• New `ArtifactTypeDef::merge_in_place(&mut self, other)` with per-field union semantics
• New `LinkTypeDef::merge_in_place` mirrors the shape for link-types (union `source-types` / `target-types`)
• Free helper `merge_named_vec` does union-by-name on `Vec`
• `Schema::merge` switches from `insert` to `entry().{merge_in_place | insert}` for both type maps

Merge semantics per field

Field	Behaviour
`description`	later wins when non-empty
`fields`, `link_fields`	union by `name`; later wins on same-name conflicts (so an overlay can change a field's `required` or `field_type` deliberately)
`shorthand_links`, `common_mistakes`	append / extend
`yaml_sections`	union with dedup
`aspice_process`, `example`, `yaml_section`, `yaml_section_suffix`	later-`Some` wins
Link-type `source_types` / `target_types`	union with dedup
Link-type `inverse`	later-`Some` wins

Test plan

Six new regression tests in `schema::tests`:

Test	Pins
`merge_same_name_artifact_type_unions_fields`	Base's `fields` survive overlay merge
`merge_same_name_artifact_type_unions_link_fields`	Base's `link_fields` survive overlay merge
`merge_preserves_shorthand_links_from_parent`	Secondary symptom: parent `shorthand_links` survive overlay redeclaration
`merge_idempotent_with_same_file_twice`	Self-merge is a no-op
`merge_order_independent_for_disjoint_additions`	Two non-conflicting overlays produce the same shape in any order
`merge_same_name_link_type_unions_target_types`	Link-type `target_types` union, base `inverse` survives

• `cargo test -p rivet-core --lib` → 980 passed, 0 failed
• All 6 new `merge_*` tests pass
• Existing schema-merge tests pass (idempotence preserved)
• CI run

Secondary symptom from #154 (stpa-yaml shorthand)

The issue body also reports that `stpa-yaml` shorthand isn't expanded into the link graph when a child schema redeclares a type. This fix collapses that symptom automatically: `Schema::merge` builds `shorthand_links` from the type's `link_fields`, and the previous insert-based merge dropped the parent's `link_fields` — so the shorthand expansion in `yaml_hir::extract_section_item` silently stopped working. With union-merge, the parent's `link_fields` stay; the shorthand expansion keeps working. No separate code change needed; the regression test `merge_preserves_shorthand_links_from_parent` guards this path.

Backward-compat

Projects that relied on replace behaviour were already re-declaring every parent field (per the G.2 warning in `rivet-cli/src/quickstart.md`). For them, the union is a no-op — same-name fields just stay identical. The new failure mode is "deliberate parent-field removal", which has no syntax today (no `remove-fields:` or `override: true` marker), so removing that capability isn't a regression. If a future RFC adds explicit override semantics, that's an additive change.

The G.2 advice in `quickstart.md:569-577` becomes obsolete after this lands — worth a follow-up doc edit.

Trailer

`Fixes: #154` · `Implements: REQ-010` (schema) · `Refs: REQ-004` (validation correctness)

🤖 Generated with Claude Code

[github-actions]

📐 Rivet artifact delta

No artifact changes in this PR. Code-only changes (renderer, CLI wiring, tests) don't touch the artifact graph.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Rivet Criterion Benchmarks'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: f85e2ea	Previous: fd4cf19	Ratio
link_graph_build/10000	41232527 ns/iter (± 2308992)	30575891 ns/iter (± 2813963)	1.35
query/10000	142236 ns/iter (± 1033)	110844 ns/iter (± 721)	1.28

This comment was automatically generated by workflow using github-action-benchmark.

[codecov]

Codecov Report

❌ Patch coverage is 98.24561% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
rivet-core/src/schema.rs	98.24%	4 Missing ⚠️

📢 Thoughts on this report? Let us know!