Codex owns the retry

[vitramir]

A codex error notification carries will_retry — whether codex is retrying the turn itself. The daemon parsed it, logged it, and then ignored it, deciding instead by substring:

var retryableCodexErrorNotificationTerms = [...]string{
	"stream disconn", "stream disconnected", "connection reset", ...
}

What that cost

A response that completes carrying no assistant message is reported as stream disconnected before completion with will_retry=false. That is an ordinary thing for a model to return — captured live on a platform VM, every stream reaching the proxy ended response.completed with zero output_text.delta events, and metering recorded them success with real output tokens.

The daemon matched "stream disconn", overruled codex, and restarted the turn under a new id. Same request, same answer, again — six turns for one message, backing off 1s, 2s, 4s, 8s, ending in produced no text:

codex bridge: error notification: ... will_retry=false message=stream disconnected before completion
codex turn transient failure: ... retrying sync
sync messages retry failed: ... retrying in 1s
... x6
codex turn ... produced no text for message ...

Change

notification	before	after
transient term, will_retry=true	retry	retry
transient term, will_retry=false	retry storm	turn ends: nothing posted, message acked
no matching term	terminal	terminal

Scoped to the transient class on purpose: gating on will_retry alone also swallows notifications matching none of the terms, which an existing test caught, so those stay terminal.

Not in this PR

retryableCodexErrorNotificationTerms is an allowlist, so a transient failure codex words differently still exits the daemon. will_retry answers that half too and would retire the list entirely — worth doing, deliberately not widened here.