Represent multi-origin target groups with shared-world provenance

[danielgwilson]

Problem

Some product labs expose multiple browser origins or surfaces that all belong to one prepared test world: for example, separate user/admin/operator frontends backed by the same seeded database or service plane. A target roster can hand Mimetic per-lane URLs, but the run bundle also needs to prove that those different targets came from one coherent prepared world, not unrelated deployments.

This is adjacent to #206 and #164: #206 covers preparing lane targets, and #164 covers shared-world topology. This issue is the provenance contract between them for multi-origin target groups.

Proposal

Extend the target-roster/shared-world model with safe provenance fields such as:

{
  "schema": "mimetic.target-roster.v1",
  "worldId": "prepared-world-001",
  "targetGroup": "checkout-smoke",
  "planeDigest": "sha256:...",
  "lanes": [
    {
      "id": "lane-01",
      "target": "https://example.test/user",
      "surface": "user",
      "targetGroup": "checkout-smoke"
    },
    {
      "id": "lane-02",
      "target": "https://example.test/admin",
      "surface": "admin",
      "targetGroup": "checkout-smoke"
    }
  ]
}

Persist only safe IDs/digests/labels in the run bundle; never require raw private URLs in public/share-ready summaries.

Acceptance

• A roster can declare that multiple target origins/surfaces belong to one prepared world.
• Verify/review output exposes world/target-group provenance and fails closed if lanes expected to share a world are inconsistent or missing provenance.
• Observer/readback can group lanes by target group/world.
• The contract composes with Add target-roster prepare contract for app-url CUA fanout #206 target-roster prepare and Multi-actor shared-world (shared-service) topology (proof-roadmap layer 7) #164 shared-world topology.

Public-safety stance

Generic OSS capability. Examples must use synthetic app names and placeholder URLs only.