docs(ipc): simplify handle-push wording

docs/docs/namespaces/ipc.md

@@ -3,7 +3,7 @@
 Connect to a Rayforce server (`./rayforce -p <port>`) and exchange messages over TCP. The wire format is the same compact binary serialisation used for `ser`/`de`, with automatic delta+RLE compression for payloads larger than 2,000 bytes. All five connection builtins live here; the server-side connection hooks (`.ipc.on.open` / `.on.close` / `.on.sync` / `.on.async` / `.on.auth`) live on the [IPC Connection Hooks](../storage/ipc-hooks.md) page — they are user-settable lambda slots, not registered builtins, so they don't appear in the reference table below.
 
 !!! note "One handle namespace"
-    A handle is a handle, whichever side of the wire you are on: the `i64` returned by `.ipc.open` and the `h` a server-side hook receives (or reads via `.ipc.handle`) name connections in the same namespace, and `.ipc.send`, `.ipc.post`, and `.ipc.close` accept either. A server can therefore push messages back through the handle its hooks were given — from inside the hook or any time later — kdb-style. Handles are only meaningful inside the process that owns the connection; they are not stable identifiers across processes or reconnects.
+    A handle is a handle, whichever side of the wire you are on: the `i64` returned by `.ipc.open` and the `h` a server-side hook receives (or reads via `.ipc.handle`) name connections in the same namespace, and `.ipc.send`, `.ipc.post`, and `.ipc.close` accept either. A server can therefore push messages back through the handle its hooks were given — from inside the hook or any time later. Handles are only meaningful inside the process that owns the connection; they are not stable identifiers across processes or reconnects.
 
 !!! note "Restricted under `-U`"
     `.ipc.open`, `.ipc.close`, `.ipc.send`, and `.ipc.post` are `RAY_FN_RESTRICTED` — IPC chaining is blocked on a `-U` server (a peer cannot dial outward to a third server). `.ipc.handle` is always available so hooks can read the current connection ID.

src/core/ipc.c

@@ -1277,7 +1277,7 @@ int ray_ipc_poll(ray_ipc_server_t* srv, int timeout_ms)
  * ray_ipc_connect).  Every entry point below resolves the handle in the
  * "active" poll (the poll dispatching the current hook/eval, else the
  * runtime's main poll), so server-side code can write to the very
- * handles its hooks receive — kdb-style server push. */
+ * handles its hooks receive — server-initiated push. */
 
 static int64_t recv_full(ray_sock_t fd, void* buf, size_t len) {
     size_t total = 0;