docs(adr): compress to 2 records in the domain-modeling format

docs/adr/0001-protobuf-request-message-not-a-provider.md

@@ -0,0 +1,12 @@
+# The protobuf request message is not exposed as a provider
+
+`grpc_context_provider` binds `grpc.ServicerContext` at `Scope.REQUEST` and nothing else, even
+though every unary-request RPC has its protobuf `Message` in hand when the child container is built.
+Binding it would force a `protobuf` import to declare the provider's `bound_type`, adding a runtime
+dependency to a package that otherwise needs only `grpcio` and `modern-di`, and buying nothing: gRPC
+already hands the request to the servicer method as its first positional argument. It would also be
+uneven, because client-streaming RPCs receive an iterator rather than a single message, so the
+provider would resolve for two of the four RPC types and raise for the other two. `ServicerContext`
+is present for all four, and being the only connection provider is why `_build_child` calls
+`integrations.bind` directly rather than `classify_connection`. A request message needed
+transitively, several provider edges deep, is the case that would reopen this.

docs/adr/0002-streaming-servicer-methods-must-be-generators.md

@@ -0,0 +1,12 @@
+# Response-streaming servicer methods must be generators
+
+The response-streaming contract is the idiomatic (async) generator servicer form only: a method that
+returns nothing and streams by calling `context.write(...)` is not supported, and `inject` keeps its
+three wrapper shapes rather than growing a fourth to detect one. gRPC accepts both forms, and
+dishka's grpcio integration handles the `context.write` coroutine as well, but the two need opposite
+lifetimes. A generator behavior is consumed lazily, so `_wrap_stream_sync` and `_wrap_stream_aio` are
+themselves generators that keep the per-RPC child and its `ContextVar` alive for as long as the
+stream runs, while a `context.write` behavior is a plain coroutine that wants the response-unary
+wrapper. `inspect` cannot tell the two apart, and guessing unary for a generator closes the child
+before gRPC pulls a single item, tearing down every resolved dependency mid-stream. Supporting the
+other form takes an explicit opt-in, never a runtime guess.

docs/agents/domain.md

@@ -17,8 +17,8 @@ Single-context repo:
 /
 ├── CONTEXT.md
 ├── docs/adr/
-│   ├── 0001-aio-coverage-flake-fixed-in-the-test.md
-│   └── 0002-protobuf-request-message-not-a-provider.md
+│   ├── 0001-protobuf-request-message-not-a-provider.md
+│   └── 0002-streaming-servicer-methods-must-be-generators.md
 └── modern_di_grpc/
 ```
 
@@ -32,4 +32,5 @@ If the concept you need isn't in the glossary yet, that's a signal: either you'r
 
 If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
 
-> _Contradicts ADR-0001 (aio coverage flake fixed in the test), but worth reopening because…_
+> _Contradicts ADR-0001 (the protobuf request message is not exposed as a provider), but worth
+> reopening because…_