fix(llm): split OpenAI reasoning summary blocks - #29000

- Mirror official ResponseIncludable union from openai-node SDK as the
  single source of truth for OpenAIResponseIncludables. Export a typed
  Schema and a string Set for filtering.
- Remove the duplicate includeEncryptedReasoning boolean alias. Callers
  pass include: ReadonlyArray<OpenAIResponseIncludable> directly.
- Tighten the wire schema in openai-responses.ts to the full SDK union
  instead of a single hand-coded literal.
- Re-export the type from providers/openai-options.ts so existing
  facade consumers keep the same import surface.
- Update internal test scenarios to use the canonical include array.

No behavioral change at the wire level; the only previously-accepted
input shape (the boolean alias) is now unsupported in favor of the
schema-aligned array.

…ptions

The native @opencode-ai/llm SDK keeps two ways to request encrypted
reasoning state, which serve different audiences:

- include: ReadonlyArray<OpenAIResponseIncludable> is the canonical
  OpenAI Responses wire field. Mirrors the official SDK union and is
  what opencode emits via ProviderTransform.options when routing
  through the native runtime.
- includeEncryptedReasoning: boolean is a native-SDK-only convenience
  for direct @opencode-ai/llm callers that only need the encrypted
  reasoning category. Explicit include wins when both are set.

OpenAIOptions.include() filters incoming arrays against the official
ResponseIncludable union so a typo in upstream config silently drops
the invalid entry instead of poisoning the request.

Re-export OpenAIResponseIncludable from the OpenAI provider facade so
external consumers can spell the union without reaching into protocol
internals.

Document the AI SDK -> native pass-through in native-runtime.ts so the
boundary is visible: provider options share field names with the
official OpenAI wire shape, so this is a pass-through, not a
translation. Tests cover the union, filtering, the boolean alias, and
the explicit-include precedence.

- Require non-empty itemId in OpenAI lowerReasoning so the store-true
  and store-false branches behave consistently.
- Hoist ["reasoning.encrypted_content"] into a single INCLUDE_ENCRYPTED_REASONING
  constant in opencode's transform.ts; five branches used to repeat the
  literal.
- Document the OpenAI Responses reasoning-event ordering assumption above
  the handler set so the implicit contract is visible.
- Replace Object.fromEntries(entries.filter(...)) with a destructure-rest
  in onOutputItemDone reasoning cleanup.

…the only API

The native OpenAI options accepted two ways to request encrypted
reasoning (`include` array and `includeEncryptedReasoning` boolean),
which forced a precedence rule and surfaced edge cases like `include:
[]` clashing with `includeEncryptedReasoning: true`. There should
either be one option with a translation layer between AI SDK options
and native LLM options, or both sides should share the same array
shape with the translation layer being identity. Choose the latter:

- Remove `includeEncryptedReasoning` from OpenAIOptionsInput entirely.
- `OpenAIOptions.include` is now a pure filter over the official
  ResponseIncludable union; an empty or all-invalid array returns
  undefined.
- Update tests and docs accordingly. The AI SDK -> native boundary in
  native-runtime.ts is identity (both surfaces use OpenAI's wire field
  names verbatim); if a future field needs translation, that's the
  one place it belongs.

The field was removed from OpenAIOptionsInput in the previous commit,
but openAIProviderOptions still read `options?.includeEncryptedReasoning`
into the emitted providerOptions.openai map. The index signature on
OpenAIOptionsInput meant this compiled silently — a caller upgrading
with a stale { includeEncryptedReasoning: true } would forward the
value to a key nothing reads. Delete the line.

Also tighten summaryParts to Record<number, ReasoningSummaryStatus>
since every write uses event.summary_index (a number).

…emId-only drop"

This reverts commit 90619cc.