fix(cli): cdk list pollutes stdout with synth and dependency status lines

[sai-ray]

cdk ls prints status lines like ✨ Synthesis time: X.XXs and Including dependency stacks: ... alongside the stack listing. In CI these go to stdout, next to the listing, which breaks scripts that parse the output (issue aws/aws-cdk#38165).

#1637 tried to fix this by suppressing the synth-time message under --json, but plain cdk ls in CI was still affected, and the dependency line was never handled.

Both lines now get suppressed on the list path so stdout is only the listing. The dependency line got a message code in #1677 so it can be targeted by code, same as the synth-time line:

this.ioHost.once(IO.CDK_TOOLKIT_I1000, () => ({ preventDefault: true }));
this.ioHost.once(IO.CDK_TOOLKIT_I1002, () => ({ preventDefault: true }));

This applies in all cases, not just CI or --json.

Before:

After:

Tests

• Unit: both suppressors are registered on the list path.
• Integ: cdk ls in CI produces only the stack listing, no status lines.

Checklist

• This change contains a major version upgrade for a dependency and I confirm all breaking changes are addressed
  • Release notes for the new version:

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[mrgrain]

Just disable them for any case please. Let us not get confused by reports saying this happens in CI. It happens everywhere.

[sai-ray]

Converted to draft while I rework this.

The current approach raises the log level to warn during listing. It works, but it's pretty blunt, it mutates shared ioHost state and ends up swallowing other info output during the call too.

So I was thinking of giving the "Including dependency stacks" line its own message code. Then I'd suppress that and the synth-time line by code on the list path. Feels self contained and matches what we already do. Does that sound right to you, would you go about it differently?

[mrgrain]

I am CERTAIN there is a second message we need to silence as well.

[mrgrain]

I struggle understanding what we are trying to achieve here. Can you please structure the PR to show relevant screenshots of the pre #1603 output (have one for every mode you are interested in) and than include screenshots of today's output.

This way it will be abundantly clear which messages got introduced and how this PR is fixing it.

[mrgrain]

this doesn't seem like the right approach

[sai-ray]

reworked to suppress both lines by message code (no gate). Second message was the dependency line, registered it in #1677 and suppressed here. Updated the PR description with pre and post screenshots.