refactor: framework modules log through diary components

- Each module logs through diary.For(<package>): cabana, lagoon, attach, cooler, postcard, beachcomber, lighthouse, centrifugo, flare, phrasebook, wristband, bouncer
- App-published *slog.Logger overrides stay first; messages and attributes unchanged
- sunscreen: InstallDefault documented as the compatibility entry point; diary wraps every channel
- READMEs list diary as a dependency; logging docs: plugins use diary.For

docs/services/logging.md

@@ -130,7 +130,15 @@ logger.Info("vendor call failed",
 
 ## Logging from a plugin
 
-A plugin resolves a `*slog.Logger` from the application with `backpack.Lookup` and falls back to `slog.Default` when none is published, as the framework modules do. Either way the record goes through the redacting handler.
+A plugin logs through its own component logger, named after its plugin code without dots, instead of the process default logger. The logger is safe to create in a package `var` block, before diary is set up:
+
+```go src=modules/diary/example_test.go#blogLog
+// blogLog is the component logger of a blog plugin, created once in a
+// package var block, before diary is set up.
+var blogLog = diary.For("blog")
+```
+
+Its records carry `component=blog`, follow `log.components.blog` and go through the redacting channels.
 
 Redaction is a safety net for mistakes, not a way to log secrets on purpose. Log identifiers and outcomes: the record id, the vendor, the status code, how long it took. Never log request arguments, tokens, credentials or request and response bodies, which can carry personal data the patterns do not recognise.