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/lagoon/README.md

@@ -12,6 +12,16 @@ Postgres data layer: the shared GORM connection, per-plugin migrations, model he
 
 `lagoon` is the WinterCMS models and migrations counterpart: it opens the one `*sql.DB` pool (pgx stdlib driver) that GORM and the rest of the application share, runs each plugin's gormigrate set in its own history table, and ports the Eloquent model conventions that WinterCMS plugins rely on, such as `$fillable`, `$hidden`, `$jsonable`, encrypted casts and Laravel-style validation rules. Its `attach` subpackage ports WinterCMS's `system_files` attachments, storing originals and lazily generated thumbnails in a gocloud.dev blob bucket. The application binary gets the migrate and key commands from `lagoon.RuntimeCommands`.
 
+## Role in the framework
+
+The data layer every stateful module builds on. It uses `backpack`, `compass`, `pact`, `party`, `phrasebook` and `bonfire`, and `cabana`, `conga`, `lighthouse`, `beachcomber` and `surf` depend on it. It is the counterpart of Eloquent and the migrator: one shared GORM connection, migrations owned by each plugin, and after-commit hooks other modules build on.
+
+Use cases:
+
+- Define a plugin's models and ship its migrations with it, with the last one rolled back while developing.
+- Attach files and images to models, stored through the blob bucket.
+- Run work after a transaction commits, which jobs, broadcasts and search sync all rely on.
+
 ## Features
 
 - One shared pool: `lagoon.Open`, `lagoon.Use` and `lagoon.OpenFromApp` return a `*sql.DB` and a `*gorm.DB` built on that same pool; `lagoon.Publish` makes both available on the `backpack.App`.