Steps ending in content_filtered or output-less max_tokens settle as succeeded with empty output

[clopca]

Description

Two settlement paths record failures as success on Bedrock:

1. POST /api/session/:id/generate returns {"data":{"text":""}} with HTTP 200 when the stream finishes content_filtered, or finishes max_tokens without any text or tool call.
2. In the runner, a step finishing max_tokens with reasoning-only output (no text, no tool call) settles as succeeded. The user sees an empty assistant message recorded as success.

The filtered terminal segment also stays in session history: replaying a real session with its full history returns empty text on every subsequent generation, and removing just the content_filtered segment makes the same history respond normally again.

In an audit of two workspaces (~1,500 sessions), 194 Fable sessions and 10 Opus sessions were recorded succeeded with assistant messages containing no text and no tool calls; 552 turns held reasoning only after hitting max_tokens.

I have a fix ready and will open a PR: session.generate raises ContentPolicyError on content-filter and InvalidProviderOutputError on output-less length; the runner publisher settles reasoning-only length as provider.invalid-output while keeping the reasoning and rawFinish for diagnosis. Truncated responses with partial text remain successful.

Plugins

opencode-bedrock-rotate (bearer token rotation; not related)

OpenCode version

0.0.0-beta-18743, also reproduced on 0.0.0-dev-18806

Steps to reproduce

1. Get a Bedrock response that ends content_filtered (or max_tokens spent entirely on reasoning, e.g. adaptive thinking with a low effective budget).
2. The step settles as succeeded with an empty assistant message.
3. POST /api/session/:id/generate on that session returns {"data":{"text":""}} with HTTP 200 from then on.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Turns truncated at the output limit are recorded as normal completions #40146: "Turns truncated at the output limit are recorded as normal completions" — covers the same finishReason: "length" treated as successful completion scenario, including the reasoning-only truncation case
• Truncated tool calls are misclassified and unrecoverable (finishReason: length + repairToolCall + doom loop) #18108: "Truncated tool calls are misclassified and unrecoverable (finishReason: length + repairToolCall + doom loop)" — broader umbrella issue covering related truncation misclassification

Your report adds distinct elements not fully covered by those issues (the content_filtered case, Bedrock-specific replay poisoning, and the audit data), so if you believe this is a separate bug or your proposed fix differs from the approaches in the above issues, please clarify so maintainers can track the novel parts separately.