Fix the retry plan for an event sender

An AI agent changed your event ingestion service to retry failed sends, and described it as "graceful retry with jitter". Its first version returned success after the last retry failed, so dropped events looked delivered. It also waited a fixed time instead of adding jitter, a random part of each wait so many clients do not retry in lockstep. You are pinning the intended behavior down as a trace of what the client does.

An assistant wrote plan_retry_attempts(attempt_results, max_retries), which produces that trace. It is in the editor. It has a bug. Find it and fix it.

Input and output:

• attempt_results: what each send returns, in order. Only the exact string ok is a success. Any other value, such as err or timeout, is a failure.
• max_retries: how many attempts the client may make.
• Return the trace, a list of strings.

Rules the tests check:

• The client makes at most max_retries attempts, numbered from 0. If max_retries is 0 or less, it makes none.
• Attempt i uses attempt_results[i]. If the list has no entry i, the attempt fails.
• A successful attempt logs attempt=<i> ok, then return=ok, and the trace ends.
• A failed attempt logs attempt=<i> err. If it was not the last allowed attempt, the client then waits and logs sleep=0..<w>, where w is the longest it might wait, in ms.
• w is 100 for the first wait and doubles for each wait after it, but never goes above 3200.
• If every allowed attempt fails, or none was made, the trace ends with return=err.