Codex WS can pair a stale response ID with an advanced delta boundary

[justrach]

stepResponses() currently advances codex_sent_upto whenever a WS is live, but only replaces codex_prev_id when the parsed response contains a new response.id.

If parseResponses() returns .ok from output items without a terminal response ID (it accepts items.items.len > 0), the old ID remains while the boundary advances. The next delta request references the old server response but slices local input after the new boundary, omitting state the referenced response never held.

Relevant paths:

• src/agent_request.zig: parseResponses() accepts output items without response.completed/ID.
• src/agent_steps.zig: codex_sent_upto advances before/without requiring a new ID.
• src/agent_request.zig: buildBody() then pairs stale previous_response_id with the advanced slice.

Safe behavior: only advance the delta boundary when a new response ID is installed atomically; otherwise close/reset the WS continuation state so the next request fully re-anchors.

[justrach]

Fixed in v0.0.226 (PR #328).

codex_chain.record advanced the watermark unconditionally while codex_prev_id only moved when the response carried an id, so a response without one paired a stale id with an advanced boundary and silently dropped messages. They now move together; a response with no usable id drops the anchor and the next request re-sends full input (src/agent_steps.zig).

Tests went 449 -> 575 on this release; every Zig fix carries a pinning test that was falsified independently (revert the production change, confirm the test goes red naming itself, restore).