docs: warn that apps sharing a root container close it for each other (#700)

Author: lesnik512

docs/providers/context.md

@@ -119,7 +119,8 @@ assert with_request.resolve(AuditLog).client_host == "10.0.0.1"
 The same works with an integration's provider. With `modern-di-fastapi` set up, an
 `AuditLog(request: fastapi.Request | None = None)` gets the real request inside a FastAPI handler
 and `None` in a FastStream consumer that shares the container. The provider itself stays required,
-so `container.resolve(fastapi.Request)` outside a request still raises.
+so `container.resolve(fastapi.Request)` outside a request still raises. Both apps then close the
+same container at shutdown; see [Closing and reopening](lifecycle.md#closing-and-reopening).
 
 The fallback has limits:
 

docs/providers/lifecycle.md

@@ -291,6 +291,14 @@ What survives close and reopen depends on `CacheSettings`:
     not the outer one. Use one `with` block per container, or build a child container for
     the inner scope.
 
+!!! caution "Apps that share a container close it for each other"
+    Integrations open the root container at startup and close it at shutdown, and opening an
+    open container does nothing. When two apps share one root container, for example a FastAPI
+    app and a FastStream app in one process, the first app to stop closes it and runs its APP
+    finalizers. After that, any resolve in the other app that reaches an APP-scoped provider
+    raises `ContainerClosedError`. Stop the apps together, or give each app its own container
+    when they stop independently.
+
 ## Validation
 
 `container.validate()` checks the whole graph in one pass: cycles, dependencies on a deeper scope,

docs/troubleshooting/container-closed-error.md

@@ -68,6 +68,11 @@ comes from and stop it outliving the container. Reopening there would hide the l
 cached after the reopen would never be finalized, because the shutdown that should close it has
 already run.
 
+Two apps that share one root container close it for each other. Each integration closes the root
+at its app's shutdown, so when one app stops, the other's next resolve of an APP-scoped provider
+raises. Stop the apps together, or give each app its own container. See
+[Lifecycle: closing and reopening](../providers/lifecycle.md#closing-and-reopening).
+
 A finalizer that resolves from its own container fails the same way, because the container counts
 as closed while its finalizers run. That `ContainerClosedError` arrives as an entry inside the
 [`FinalizerError`](finalizer-error.md) that `close_sync()` or `close_async()` raises. Do not reopen