docs: add a Role in the framework section to every module README

Each module README now says where the module sits in the dependency
graph, why it is its own module, and lists use cases for application
developers.

modules/party/README.md

@@ -10,6 +10,16 @@ Compiled plugin registry that orders plugins by their dependencies and runs thei
 
 `party` is the WinterCMS PluginBase and PluginManager counterpart for plugins compiled into the binary. Each plugin package calls `party.Register` from its `init` function, and the application's generated `main` calls `party.Activate` with the plugin IDs listed in its manifest. Activation validates the selection, sorts it so every plugin comes after the plugins it requires, merges plugin config, runs every Register before any Boot, and wires translations and mail templates in between. Capabilities beyond the lifecycle are declared through the interfaces in [pact](../pact/README.md).
 
+## Role in the framework
+
+The plugin lifecycle, on top of `backpack`, `pact`, `phrasebook` and `postcard`. `lagoon`, `conga`, `cabana` and `surf` ask it which plugins are active and in what order. It is the counterpart of WinterCMS's plugin manager, without autoloading: plugins are registered at build time.
+
+Use cases:
+
+- Declare that a plugin depends on another one, and have it registered and booted after it.
+- Choose which compiled plugins are active through the manifest, with missing requirements and cycles caught at boot.
+- Run Register before Boot, so plugins can wire services before they use each other.
+
 ## Features
 
 - `party.Plugin`, the descriptor every plugin implements: `party.Plugin.ID`, `party.Plugin.Requires`, `party.Plugin.Register` and `party.Plugin.Boot`.