refactor(ai): drop reasoning items when they finish

[rekram1-node]

Why

ParserState.reasoningItems is the parser's working set for in-flight reasoning items: per-summary_index fragment status, which indexes streamed deltas, and the encrypted content carried onto later summary parts. Since #45789 an entry was never removed when its item finished; output_item.done flipped open: false and left the dead entry in the map for the rest of the stream. Every later handler then checked !item?.open to ignore a reappearance of that id, and onOutputItemDone short-circuited on open === false.

That is the same replay tombstone pattern removed for messages and function calls in #46965. A finished reasoning item can only reappear on a resumed stream (background: true + starting_after), which our client never requests, so the open flag guarded inputs the parser cannot receive. The real fix that shipped alongside it in #45789 is the overlap check in step for a different reasoning item starting while one is still open; that check reads lifecycle.reasoning, not the dead entry, and is unchanged here.

What changes

• ReasoningStreamItem loses open. An entry exists while the item is in flight and is deleted on output_item.done, the same shape as state.tools.
• The !item?.open guards become !item. Deltas, summary-part events, and done finals for an unknown or finished item are still no-ops.
• onOutputItemDone no longer early-returns for open === false; the done-only path emits reasoning-start/reasoning-end from the item and records nothing.
• Removed a dead branch: lifecycle.reasoning.has(item.id) with a bare item id was always false because that set only holds ${id}:${index} keys.
• Tests: stripped duplicate done, re-added, and post-done delta events from two lifecycle fixtures and the openai-responses dedup fixture; remaining assertions are unchanged. Duplicate added for a still-pending reasoning item is still covered and still a no-op.

Verification

cd packages/ai
bun typecheck
bun run test   # 977 pass, 28 skip, 0 fail