fix(rendering): honor suppressWarnings in settled build output

[JoshKappler]

suppressWarnings was only applied to the streaming compiler-warning fragments. The settled text rendered from the domain result calls createStandardDiagnosticSections directly, which always emitted the Warnings section, so warnings still reached the final MCP tool response.

This threads the flag into the build, build-run, and test diagnostic paths. Errors still render when it is set, and other result kinds are unchanged since the option covers warnings from the build tools.

Tested with two unit tests on renderDomainResultTextItems and one regression test at the renderCliTextTranscript level, which is the surface the issue reports. That regression test fails on main and passes here. tsc --noEmit, eslint, and prettier are clean.

The issue also notes that in the CLI runtime suppressWarnings never reaches the renderer, since bootstrapRuntime only hydrates config sessionDefaults when runtime is mcp. Changing that would affect every session default in the CLI, so I left it out of this fix.

Fixes #447.

[sentry]

Bug: The suppressWarnings flag is not passed to createSpecialCaseItems, causing warnings to be displayed for install-result, launch-result, and stop-result failures even when suppression is requested.
_{Severity: MEDIUM}

Suggested Fix

Extract the suppressWarnings option from the options object at the beginning of the renderDomainResultTextItems function, before createSpecialCaseItems is called. Then, pass the suppressWarnings flag through the call chain to createSpecialCaseItems and subsequently to createFailureStatusWithDiagnostics to ensure it is respected.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/utils/renderers/domain-result-text.ts#L270-L276

Potential issue: The `suppressWarnings` option is not honored for certain failure types,
such as `install-result`, `launch-result`, and `stop-result`. This occurs because the
`renderDomainResultTextItems` function calls `createSpecialCaseItems` to handle these
results before it extracts the `suppressWarnings` flag from its options. Consequently,
`createSpecialCaseItems` calls `createFailureStatusWithDiagnostics` without the flag,
leading to `createStandardDiagnosticSections` rendering warnings even when
`suppressWarnings: true` is specified. This behavior contradicts the intended
functionality of suppressing all tool and build warnings.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[JoshKappler]

I checked this against the result constructors and I don't think the path is reachable.

Every install-result, launch-result, and stop-result is built with an empty warnings array. buildInstallSuccess, buildLaunchSuccess, and buildStopSuccess hardcode warnings: [], and the failure builders (buildInstallFailure, buildLaunchFailure, buildStopFailure) call createBasicDiagnostics({ errors: [...] }), which normalizes the absent warnings to []. swift_package_stop builds its stop-result the same way.

createStandardDiagnosticSections only emits the Warnings section when diagnostics.warnings.length > 0, so those three kinds never render one whether or not the flag is set. Threading suppressWarnings into createSpecialCaseItems would be dead code today.

The kinds that actually populate warnings are build, build-run, and test, and those are the ones this PR threads the flag into. If you would rather have the flag wired through the special-case path anyway so it cannot drift if those results ever start carrying warnings, say so and I will extend it.

[cameroncooke]

@JoshKappler thanks for this I think it would be worth creating a snapshot test and fixture for this scenario?