docs(adr): reword ADR-0007's contract to cover Litestar's application_config

docs/adr/0007-no-django-bootstrapper.md

@@ -1,8 +1,11 @@
 # No Django bootstrapper
 
-Every bootstrapper keeps one contract: the user constructs the application, passes it in, and gets
-the same object back. Django's observability is conventionally owned by `settings.py`
-(`MIDDLEWARE` ordering, installed apps), which runs before any object a bootstrapper could be handed.
+Every bootstrapper keeps one contract: it takes the user's application, or builds one from config,
+instruments it and returns it. FastAPI, FastStream and FastMCP accept an application and build a
+default one when none is passed. Litestar always builds its own with `Litestar.from_config` from the
+user's `application_config`, because its plugins and middleware must be in the `AppConfig` before the
+app exists. Django's observability is conventionally owned by `settings.py` (`MIDDLEWARE` ordering,
+installed apps), which runs before any object a bootstrapper could be handed or build.
 ADR-0001 is the calibration: FastMCP was the hardest framework to fit and still had an application
 object to attach to. Attaching to a constructed `ASGIHandler` is the shape that would fit, and today
 that means middleware outside `MIDDLEWARE`, diverging from every Django deployment guide and from

docs/integrations/litestar.md

@@ -45,6 +45,11 @@ bootstrapper = LitestarBootstrapper(bootstrapper_config)
 application = bootstrapper.bootstrap()
 ```
 
+The bootstrapper builds the `Litestar` app itself with `Litestar.from_config`, so app-level settings
+go into `application_config=AppConfig(...)` instead of an `application` argument
+([ADR-0007](https://github.com/modern-python/lite-bootstrap/blob/main/docs/adr/0007-no-django-bootstrapper.md)
+records why).
+
 Read more about available configuration options [here](../introduction/configuration.md).
 
 ## Logging