V2: improve UX for provider content-filter finishes #34835

Summary

V2 currently records provider content-filter stops as finish: "content-filter". A minimal UI patch can notice that finish reason and show a message, but the product shape still feels awkward: the turn is technically "finished", the provider blocked output, and different clients may need to explain that state consistently.

Motivating thread: https://discord.com/channels/1391832426048651334/1522072692285767831
Related prior issue: #31744
Related draft PR exploring the minimal UI-only approach: #34834

Problem

A provider can end a turn with a content-filter finish reason and no visible assistant text. In the session that triggered this, follow-up prompts like "what happened?" and "hello?" also completed with empty assistant messages and finish: "content-filter", making the model look like it stopped responding.

A schema-level error field is probably too heavy for this specific case, but simply sprinkling finish === "content-filter" checks in clients may not be the right long-term V2 UX either.

Questions

• Is finish: "content-filter" enough as the canonical protocol signal, with clients responsible for presentation?
• Should content-filter finishes produce a user-visible transcript part/notice, or just a footer/status treatment?
• Should a content-filter finish affect retry/regenerate behavior differently from stop, length, or hard provider errors?
• Should TUI, web/session UI, SDK consumers, ACP, and exported sessions all present this state the same way?
• What wording should we use so users understand the provider blocked the response, not that OpenCode hung?

Desired outcome

Pick a V2 contract and UX rule for content-filter finishes, then update clients consistently. The immediate fix should avoid unnecessary schema churn unless the team decides this really is an assistant error state.