What-if 'Potential' color (light cyan) is hard to read in GitHub Actions output

**Is your feature request related to a problem? Please describe.**

The color used for `Potential` changes in what-if output (light cyan) isn't readable in the GitHub Actions log display. GitHub Actions renders logs on a dark background, and light cyan on that background is low enough contrast that the `Potential` lines are hard to pick out — which is a problem, because those are exactly the lines a reviewer needs to look at before approving a stack update in a pipeline.

This matters more for stacks than for regular deployments, because the whole value of running what-if in CI is that a human reads the output at an approval gate. If the most ambiguous change class is the hardest one to read, the gate is less useful.

**Describe the solution you'd like**

Pick a color for `Potential` that meets a reasonable contrast ratio against both light and dark terminal backgrounds, and verify it specifically in the GitHub Actions and Azure DevOps log viewers rather than only in a local terminal.

Failing that, either of these would help:

- Respect `NO_COLOR` / provide an explicit switch to disable ANSI coloring, so pipelines can fall back to the symbol/label prefix alone.
- Make the change-type label itself unambiguous in plain text, so color is decoration rather than the primary signal.

**Describe alternatives you've considered**

Stripping ANSI codes in the pipeline step. That makes the output readable but loses the color coding entirely for every change type, not just `Potential`.

**Additional context**

Raised by a customer during early adoption of stacks what-if after GA, running it in GitHub Actions. Related to #244, which covers the layout and resource ID display of the same output; this issue is specifically about color contrast/readability.

No file or test is named. Start with the what-if output path that assigns the Potential color and reproduce it in GitHub Actions and Azure DevOps log viewers. Done means Potential is readable against both backgrounds, with the stated NO_COLOR or unambiguous plain-text fallback considered if contrast alone is insufficient.

Written by the indexing model from the issue text.