[docs] Document stream encryption key lookup failures for writes to another run

.changeset/docs-cleanup-oct-29.md

@@ -0,0 +1,4 @@
+---
+---
+
+Docs: document how stream writes to another run handle encryption key lookup failures, including the `RUNTIME_ERROR` run classification.

docs/content/docs/v5/foundations/errors-and-retries.mdx

@@ -170,7 +170,7 @@ On Vercel, backend connection failures and interrupted event streams use the exi
 
 The SDK also replaces its shared events connection pool after repeated HTTP/2 session failures, and retries event-log reads whose HTTP/2 stream the backend resets. An events request that receives no response data for 60 seconds fails and is retried instead of stalling the invocation. Invalid backend URLs, including unsupported protocols and embedded credentials, fail immediately. Fetch requests to blocked ports or with unsupported headers (such as `Expect`) also fail without retrying. Interrupted event writes retain their existing retries; caller cancellations do not trigger another write.
 
-Writing to a stream forwarded from another run looks up that run's encryption key first. A transient lookup failure (a connection error, a timeout, an HTTP `429`, or a `5xx`) uses the step's retry policy. Any other lookup failure, such as an HTTP `404` when the owner run no longer exists, fails the step without retrying, with a `EncryptionKeyLookupError` whose `cause` is the original failure.
+Writing to a stream forwarded from another run looks up that run's encryption key first. A transient lookup failure (a connection error, a timeout, an HTTP `429`, or a `5xx`) uses the step's retry policy. Any other lookup failure, such as an HTTP `404` when the owner run no longer exists, fails the step without retrying, with an `EncryptionKeyLookupError` whose `cause` is the original failure. Uncaught, an `EncryptionKeyLookupError` fails the run with the `RUNTIME_ERROR` code. Outside a step, such as in an API route, nothing retries the write. The stream rejects with the transient failure itself or with an `EncryptionKeyLookupError`.
 
 A connection failure does not prove that the backend rejected a write: it may have accepted it before the response was lost. Continue to make step side effects [idempotent](/docs/foundations/idempotency).
 

docs/content/docs/v5/foundations/streaming.mdx

@@ -340,7 +340,7 @@ Pass `{ namespace: "name" }` to target a [namespaced stream](#namespaced-streams
 Contributors should call `releaseLock()`, which flushes pending writes. Calling `close()` closes the shared stream for every writer. Calling `abort()` keeps the chunks already written and leaves the shared stream open.
 </Callout>
 
-The API grants append access, not read access or additional authorization. The owning run controls the stream's lifecycle, and writes to an unknown run fail.
+The API grants append access, not read access or additional authorization. The owning run controls the stream's lifecycle, and writes to an unknown run fail without retrying. Inside a step, a transient failure to look up the owning run's encryption key, such as an HTTP `429` or `5xx`, retries the step. See [Backend connection failures](/docs/foundations/errors-and-retries#backend-connection-failures).
 
 ## Common patterns