Docs for key renames: ids and keys in the flow concepts, the rename routes, events and 503s in the API reference, hooks during a rename, sync and run metrics after one; a pinned restore refused for its recorded key names that key in the 409

docs/reference/node-types.md

@@ -63,7 +63,9 @@ The ports pick the direction: outputs only make a **listener**, inputs a
 **sender**. A listener is a **webhook**: the engine mounts a route at
 `/hooks/{flow id}/{url}/{secret}` while the flow runs. The flow's id is in the
 URL rather than its key, so the URL stays the same when the key changes, and
-for a flow made before ids existed it reads as the key. A sender requests `url`
+for a flow made before ids existed it reads as the key. While a rename rewrites
+the flow, the hook answers 503 with `Retry-After`, and a served socket closes
+with code 1013, try again later. A sender requests `url`
 and publishes a JSON object response on its outputs, one key per output port.
 Keys no port declares are dropped, and a response that is not an object
 publishes nothing.