bump zat v0.3.0-alpha.21 → v0.3.1, websocket 9ac64da → 3c6794a master
picks up websocket 3c6794a "fix handshake: POST with body hangs httpFallback dispatch" — Handshake.parse used endsWith("\r\n\r\n") to decide when the buffer held a complete request, which only worked for header-only (GET) requests. POST with body never matches → parse returns null forever → caller reads more → connection idles until external timeout. operator-observed symptom in the 2026-05-04 handoff: requestCrawl (and every other POST endpoint with a body) hangs ~11.6s with zero response bytes, no log line, no DB mutation. the empty-body POST worked because that buffer DOES end with "\r\n\r\n", reaching parseHttpRequest correctly. the entire reconnect cron has been dead since whenever this regression landed in the websocket fork. zat v0.3.1 was the right pin to take — it's the released stable version and already uses the fixed websocket commit transitively. both zat and zlay now resolve the same websocket package, avoiding the multi-module conflict that surfaced when only zlay's pin moved. post-deploy verification (operator): - POST requestCrawl with body should now respond fast (200 or 400) - "requestCrawl received" log line fires on every POST - cron drains under 30min activeDeadlineSeconds - relay_db_queue_depth oscillates near 0 (ee4fa88 holds) Co-Authored-By: Claude Opus 4 (1M context) <noreply@anthropic.com>