Export runtime plugin projection coverage

docs/eve-migration-roadmap.md

@@ -331,10 +331,16 @@ Recently cut:
   owners can consume the coverage ledger without walking Eve's nested plugin
   records.
 - Provider/plugin requirement coverage is now exported as root
-  `providerPluginRequirementCoverage[]` records. The plugin-owner smoke asserts
-  the Sai VN provider surface requirements for `sai.vn`, `norn.graph`, and
-  `tex.math` as satisfied by their owning plugin repos, keeping provider
-  requirements separate from runtime projection support.
+  `providerPluginRequirementCoverage[]` records with availability. The
+  plugin-owner smoke asserts `sai.vn` as the required VN plugin and
+  `norn.graph` / `tex.math` as `optional-satisfied` nested plugins owned by
+  Norn and EvePlugins. A Sai surface can embed Norn or TeX when those plugins
+  are available, but Sai does not own their graph or math semantics.
+- Runtime/plugin projection claims are now exported as root
+  `runtimePluginProjectionCoverage[]` records. Runtime-owner smokes assert
+  Unity UI Toolkit support for `sai.vn` and `norn.graph`, its declared TeX gap,
+  and the pending Unity scene/Electron unsupported Sai projection until their
+  generic lowerers exist.
 - Runtime/plugin projection gaps are now exported as
   `runtimePluginProjectionGaps[]`. The runtime-owner smoke asserts Unity and
   Electron plugin gaps as typed records, so missing Sai, Norn, or TeX projection

docs/parity-testing-harness.md

@@ -141,6 +141,13 @@ split target, plugin id, reason, severity, and fixture lists so EveUnity,
 EveElectron, Sai, Norn, and TeX owners can distinguish "runtime cannot project
 this plugin yet" from "plugin semantics belong in Eve core." Consumer smokes can
 assert them with `--expect-runtime-plugin-gap <runtimeId:pluginId:ownerRepo>`.
+The same claims are exported as `runtimePluginProjectionCoverage[]`, including
+positive `supported` projection adapters and declared `unsupported` gaps. This
+lets runtime and plugin owners consume one ledger for "Unity UI Toolkit supports
+Sai/Norn projection" and "Unity scene/Electron do not have generic plugin
+projection yet" instead of walking nested runtime records. Consumer smokes can
+assert entries with
+`--expect-runtime-plugin-projection <runtimeId:pluginId:status:ownerRepo>`.
 
 The conformance export includes runtime `capabilityManifestPath` and
 `capabilityManifestErrors` fields so external consumers can distinguish a
@@ -162,10 +169,12 @@ expect keys. Plugin-owner smokes can assert contracted operations with
 without walking nested plugin records.
 Provider-advertised plugin requirements are indexed as root
 `providerPluginRequirementCoverage[]` records. These join provider id, surface
-id, plugin id, plugin owner, plugin status, required capabilities, and missing
-capabilities so provider and plugin owners can consume requirement coverage
-without reconstructing the provider/plugin join. Consumer smokes can assert
-them with
+id, plugin id, plugin owner, plugin status, availability, required
+capabilities, optional capabilities, and missing capabilities so provider and
+plugin owners can consume requirement coverage without reconstructing the
+provider/plugin join. `availability: optional-nested` means the parent surface
+can host that independent plugin when available; it is not a parent-plugin
+dependency. Consumer smokes can assert them with
 `--expect-provider-plugin-requirement <providerId:surfaceId:pluginId:status:pluginOwnerRepo>`.
 
 The runtime conformance pack is evidence-shaped, not fixture-shaped. Its

docs/plugin-architecture.md

@@ -316,19 +316,23 @@ Recommended discovery path:
 
 1. A plugin publishes a plugin advertisement through CultMesh/Odin or ships a
    local package manifest.
-2. A provider advertisement names the plugins its surfaces require.
+2. A provider advertisement names the plugins its surfaces require and the
+   optional nested plugins it can use when available.
 3. Odin indexes providers and plugins separately.
 4. A renderer asks Odin for the provider surface and the required plugin
    manifests.
 5. The renderer checks local plugin support.
 6. Unsupported required plugin capability becomes a visible capability gap.
-7. Optional unsupported capability becomes a visible degraded lowering.
+7. Unsupported optional nested plugin capability becomes a visible degraded
+   lowering, not a claim that the parent plugin owns that nested semantic.
 
 Eve's parity harness validates this boundary directly: provider-advertised
 `surfaces[].requiresPlugins[]` entries must name known plugin manifests, and
-each `requiredCapabilities` item must be claimed by that plugin manifest. This
-keeps plugin requirements in the provider advertisement instead of hiding them
-in runtime lowerers or fixture-only metadata.
+each `requiredCapabilities` item must be claimed by that plugin manifest. Entries
+with `availability: optional-nested` are reported separately so a Sai surface can
+embed Norn or TeX when those plugins are available without making them Sai
+dependencies. This keeps plugin requirements in the provider advertisement
+instead of hiding them in runtime lowerers or fixture-only metadata.
 
 Provider advertisement sketch:
 
@@ -344,10 +348,20 @@ Provider advertisement sketch:
         {
           "pluginId": "sai.vn",
           "versionRange": "^0.1.0",
+          "availability": "required",
           "requiredCapabilities": [
             "vn.stage",
             "story.choose"
           ]
+        },
+        {
+          "pluginId": "norn.graph",
+          "versionRange": "^0.1.0",
+          "availability": "optional-nested",
+          "requiredCapabilities": [],
+          "optionalCapabilities": [
+            "embed.norn"
+          ]
         }
       ]
     }

docs/provider-advertisement-contract.md

@@ -84,10 +84,14 @@ Required top-level meanings:
   and ownership rule. Runtimes use it to decide how to lower the surface and
   where command intents must return; they do not gain authority over world
   state because they can render it.
-- `surfaces[].requiresPlugins`: sidecar plugin capabilities required to render
-  or interact with that surface. Runtimes compare these requirements with their
-  local projection support and report visible capability gaps; they must not
-  import provider or plugin internals to recover missing semantics.
+- `surfaces[].requiresPlugins`: sidecar plugin capabilities used by the
+  surface. Entries may be `availability: required` or
+  `availability: optional-nested`. Required entries gate full surface
+  interaction. Optional nested entries, such as a Sai-authored scene slotting in
+  Norn or TeX, degrade when unavailable; they do not make the parent plugin own
+  the nested plugin's semantics. Runtimes compare these entries with local
+  projection support and report visible capability gaps; they must not import
+  provider or plugin internals to recover missing semantics.
 - `commands`: command boundaries the provider accepts.
 - `routes`: transport, store, or compatibility routes used to reach the
   semantic address. WebSocket and HTTP routes live here when they still exist.