docs: record the five Phase 8 prerequisites, and report contributions

Bring the living documentation in line with what the five passes actually
shipped, and correct the claims they superseded rather than leaving them to
mislead: the module UI context is six members, not five; module styling is
compiled CSS, not inline objects only; the strict manifest is version 7.

Also close a silent failure the new contribution mechanism introduces. A
contribution whose target capability nobody provides — or whose provider moved
outside its declared range — is not published, and the manifest is valid and
the artifact exists, so an operator sees a screen that renders nothing with no
error anywhere. `pnpm modules:validate` now lists each declared contribution
with its capability and range and says whether a compatible provider is
installed, and Doctor's discovery check reports the same per module. Both
derive from the publication registry the API serves from, so neither can
disagree with what a running platform would actually publish.

Co-Authored-By: Claude Opus 5 <[email protected]>

core/src/diagnostics/doctor.ts

@@ -57,6 +57,7 @@ import {
   createModuleConfigurationStore,
   createModuleLifecycleDatabase,
   createModuleLifecycleStore,
+  createModuleUiPublicationRegistry,
   type DiscoveredModule,
   discoverModuleSchemas,
   discoverModules,
@@ -316,7 +317,26 @@ function publishReport(checks: readonly DoctorCheck[]): DoctorReport {
   return Object.freeze({ checks: frozenChecks, result: deriveDoctorResult(frozenChecks) });
 }
 
+/**
+ * One line per installed module, plus — for a module that declares browser contributions (ADR 0041)
+ * — how many of them have a compatible provider among the installed set.
+ *
+ * Worth reporting because the failure it names is otherwise silent: a contribution whose target
+ * capability nobody provides, or whose provider moved outside its declared range, is simply not
+ * published, and an operator sees a screen that renders nothing with no error anywhere. The counts
+ * are derived from the same publication registry the API serves from, so this can never disagree
+ * with what the running platform would actually publish.
+ *
+ * Static only, like every other Doctor check: it reports what the *manifests* support and never
+ * claims a module is running. Enablement and dependency blocking are the lifecycle check's job.
+ */
 function safeModuleDetails(modules: readonly DiscoveredModule[]): readonly string[] {
+  const publication = createModuleUiPublicationRegistry(modules);
+  const compatible = new Set(
+    publication
+      .listContributions()
+      .map((contribution) => `${contribution.moduleId}\u0000${contribution.contributionId}`),
+  );
   return modules.map((module) => {
     const id = module.manifest.id;
     const version = module.manifest.version;
@@ -326,7 +346,16 @@ function safeModuleDetails(modules: readonly DiscoveredModule[]): readonly strin
     ) {
       throw new TypeError("Unsafe module diagnostic value.");
     }
-    return `${id} ${version}`;
+    const declared = module.contributions.length;
+    if (declared === 0) {
+      return `${id} ${version}`;
+    }
+    const resolved = module.contributions.filter((contribution) =>
+      compatible.has(`${id}\u0000${contribution.id}`),
+    ).length;
+    return `${id} ${version} · ${declared} browser contribution${
+      declared === 1 ? "" : "s"
+    } (${resolved} with a compatible provider)`;
   });
 }