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]>

docs/development/security.md

@@ -201,7 +201,7 @@ separate deployment and threat-model decision.
 
 ### A display page is authorized; its artifact bytes are not authority
 
-Manifest version 6 binds a display artifact to one permission declared by the same module
+The manifest binds a display artifact to one permission declared by the same module
 ([ADR 0033](../architecture/decisions/0033-display-kiosk-host-contract.md)). The declaration rejects
 a `public` baseline: the current display host requires an ordinary authenticated cookie principal,
 and public/device identity is not approximated with an anonymous exception. Both the stable