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

@@ -16,6 +16,16 @@ The package itself knows no search server. An engine package registers itself fr
 
 `beachcomber.From` builds the app-scoped `beachcomber.Service` on first use and publishes it on the app. It installs the sync GORM callbacks through `lagoon.OnDatabase`, so they reach the production handle even though plugins boot before `serve` publishes the database. The application installs a `beachcomber.Gate`, its kill-switch, with `beachcomber.Service.SetGate`.
 
+## Role in the framework
+
+A leaf service module on top of `lagoon` and `backpack`; nothing in the framework imports it, so an application that has no search pulls none of it in. The engine is behind an interface, with a Typesense driver in the typesense subpackage, so the sync logic does not depend on one search vendor.
+
+Use cases:
+
+- Keep a search index in step with a model such as a blog post: writes after commit, deletes on delete.
+- Switch indexing off in development or tests through the application kill-switch.
+- Build reindex tooling on the on-demand sync and the drop and ensure index helpers.
+
 ## Features
 
 - Engine selection by `search.driver`: `null` (the default) or a registered engine such as `typesense`. An unknown name is a boot error that lists the registered engines. Third-party engines register with `beachcomber.RegisterEngine` and a `beachcomber.EngineFactory`; a duplicate name panics at init.