Upgrade seed types from any listed baseline, chosen by recorded origin

[callumalpass]

Problem

upgrade_from holds one baseline: the most recent previous starter. An edited seed installed from an older starter is three-way merged against that baseline, so every difference between the two starters is treated as the user's edit and silently reapplied. Seen in practice: Reader's beta.1 → beta.4 upgrade brought back a match: path_glob the publisher had removed. The lock can't help today: both engines record the pack's resource digest for every seed, even one the pack preserved or a type that existed before installation.

Change (05A, schemas, conformance)

• upgrade_from: one baseline or a non-empty list, each { digest, document, version? }. A single object stays valid (a list of one).
• Validation (invalid_type_pack): seed type resources only; digest = SHA-256 of document; distinct digests; not the desired document; same type kind and name; version, if given, matches the document.
• Seed origin in the lock: seed entries gain optional origin_digest, the publisher document the target descends from. Set on create, on upgrade (exact or merged) and when live already equals the desired document; otherwise carried forward; absent when unknown (pre-existing types, intentionally preserved targets, locks written before this change). A seed's installed digest describes the pack and MUST NOT be used as its origin.
• Planning, in order (target exists, not preserved, upgrade_from declared):
  1. live = desired → preserve
  2. live = any baseline → update with the exact desired bytes (bytes prove the origin)
  3. origin = desired → preserve (upgraded, then edited)
  4. origin = a baseline → update by three-way merge against that baseline
  5. otherwise → preserve with a reason — never a guessed baseline, and never a pack-wide conflict
• The assessment reports upgrade_baseline: { digest, version? } for every seed update.

Conformance

• examples/v0.3/seed-upgrades/: one pack (example.seed-notes) whose note starter evolves v1 (title) → v2 (+created) → v3 (+tags), so merging against the wrong baseline is observable (it drops created). Includes a version that preserves without upgrade_from, a v3 that supports only v2, and one invalid manifest per validation rule. v2 uses the single-object form, v3 a list.
• tests/v0.3/type-packs/type-packs.yaml: 13 fixtures (requirements seed_type_upgrade, seed_type_upgrade_validation), using new input.history steps (apply, write, replace) and target/lock expectations documented in tests/v0.3/README.md. Merged output is compared structurally since reformatting changed nodes is permitted.
• scripts/type_pack_model.py: an executable model of these rules that check_v03_tests.py runs for seed fixtures. Mutation check: merging against the newest baseline (today's behaviour) fails 4 fixtures; using the pack digest as origin fails 2; conflicting instead of preserving fails 2.

Compatibility

upgrade_from is still unreleased (see CHANGELOG), so its shape changes before any release. Older engines and validators reject a list; packs should adopt lists only after engines and Connect validation support them. Lock entries without origin_digest are treated as unknown origin: unedited seeds still upgrade (rule 2); edited ones are preserved with a reason instead of being merged against a guess.

Verification

check_test_levels.py, check_v03_tests.py (78 executable, 155 adapter-target), migration prototype, runtime-pack drift check: all pass.