fix: avoid format strings in FrontendUtils.console

[hej090224]

Description

FrontendUtils.console() passed a caller-controlled format parameter
straight into String.format(), which static analysis tools flag as
CWE-134 (uncontrolled format string), since the method's contract does not
guarantee the argument is a compile-time constant.

Additionally, review feedback pointed out that even after removing
String.format(), console(String, String) still let the color and
message arguments be swapped by mistake, since both were plain Strings.

Changes

• flow-server/.../internal/FrontendUtils.java:
  • The ANSI color String constants (YELLOW, RED, GREEN,
    BRIGHT_BLUE) and ANSI_RESET are replaced by a nested AnsiColor
    enum. Each constant holds its own escape code, and
    AnsiColor.wrap(String message) concatenates the code, the literal
    message, and the reset sequence.
  • console(String format, Object message) is now
    console(AnsiColor ansiColor, String message); its body is
    System.out.print(ansiColor.wrap(message));. The color and message
    arguments can no longer be confused at compile time, and the message is
    never interpreted as a format string.
  • AnsiColor is nested inside FrontendUtils (matching how other
    single-purpose enums are scoped in this package, e.g.
    BrowserLiveReload.Backend); it's public only because the sole
    external caller needs to reference the constants across modules.
  • YELLOW's color code is corrected from 111 (a light blue, not yellow)
    to 220 (a normal warning yellow), per review.
• vaadin-dev-server/.../AbstractDevServerRunner.java: the three
  FrontendUtils.console(...) call sites now pass
  FrontendUtils.AnsiColor.GREEN/RED instead of the old string
  constants.
• flow-server/.../internal/FrontendUtilsTest.java: updated to the new
  enum-based API and extended with a test asserting the reset sequence is
  appended exactly once.

Testing

FrontendUtilsTest verifies:

• a plain message is wrapped with the given color and the reset sequence
• embedded newlines in the message are preserved exactly
• messages containing %s, %c, %n, and a literal % are printed
  verbatim rather than being interpreted as format specifiers
• the reset sequence is appended exactly once

Verification commands run locally:

• mvn -pl flow-server -am -DskipITs -Dtest=FrontendUtilsTest -Dsurefire.failIfNoSpecifiedTests=false test → 4/4 passed
• mvn -pl vaadin-dev-server -am -DskipITs -DskipTests install → BUILD SUCCESS (confirms the only caller module compiles against the new AnsiColor-based signature)
• mvn -pl flow-server spotless:check → BUILD SUCCESS
• mvn -pl flow-server checkstyle:check → fails, but with the same pre-existing, unrelated parser error in flow-server/.../signals/shared/impl/MutableTreeRevision.java (a record pattern in instanceof that the bundled checkstyle grammar can't parse); this file is untouched by this PR and the failure reproduces on upstream/main without this change.

Fixes #9263

[cla-assistant]

All committers have signed the CLA.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[mcollovati]

@hej090224 could you please sign the CLA? Otherwise we cannot proceed with this PR.

[hej090224]

@mcollovati Apologies for the delayed response — I missed the CLA notification. I'll sign the CLA now via the link above.

[hej090224]

Updated (24c2c41) to address @caalador's review:

• Replaced the ANSI color String constants with a nested AnsiColor enum (console(String, String) -> console(AnsiColor, String)), so the color and message arguments can't be swapped by mistake, and AnsiColor.wrap(message) builds the escaped output.
• Applied the suggested yellow color code change (111 -> 220).
• Updated FrontendUtilsTest for the new API and added a test for the reset sequence being appended exactly once.

Tests: FrontendUtilsTest 4/4 passing; full reactor build through vaadin-dev-server succeeds (confirms the only caller compiles against the new signature); spotless:check clean.

Ready for another look whenever convenient.

[hej090224]

Hi, the latest GitHub Formatter and Flow Validation workflows are now passing, and the rerun of the TeamCity Gradle Tests also succeeded.

The remaining API-DIFF labeling, Validation, Formatter, and Validation-SlowTests statuses still point to the earlier failed TeamCity builds. Since the PR head has not changed, could the remaining TeamCity checks be rerun when convenient?

Please also let me know if the API-DIFF check requires a maintainer-applied label for the FrontendUtils.console signature change. Thanks!

[caalador]

Thank you for the contribution.
Finally merged, we need some fine tuning on the setup so we get the javaDocs checked before the merge queue.