fix(inspect): allow single-line format when breakLength is Infinity

[hamidrezaghavami]

Description

When calling util.inspect() with a breakLength configuration explicitly set to Infinity, the internal layout formatting logic should bypass multi-line chunking and formatting constraints entirely, allowing the contents to naturally evaluate on a single line.

Currently, isBelowBreakLength goes through a character length loop calculation even when length checks are logically unnecessary due to the infinite upper bound. This change introduces an explicit early return branch within isBelowBreakLength when ctx.breakLength === Infinity, properly enabling a clean, un-wrapped single-line string formatting mode.

Checklist

• Core internal utility verification

[ljharb]

this definitely needs tests to cover the changed behavior. ideally, you'd also provide the tests' output absent this change.

[hamidrezaghavami]

Hello, @ljharb The single-line formatting behaviour when breakLength is set to Infinity is covered in a test case that I have provided.
Behaviour of output for context:
Without this modification, if it causes internal length constraint checks, the output is automatically converted to a multi-line format that spans many lines.
With this modification, multi-line chunking is completely avoided by the internal layout logic, which evaluates the contents into a single line format precisely as anticipated:
"a: 1, b: 2, c: 3, d: 4 }"

[hamidrezaghavami]

@ljharb All formatting, linting, and core test suites are now fully passing (29/30 checks successful). The single remaining check (test-macOS) failed on an unrelated debugger timeout (test-debugger-exceptions.js 15000ms exceeded), which appears to be a macOS CI runner flake. Could you please re-run that failed macOS job when you have a moment to review?
Thank you!

[ljharb]

@hamidrezaghavami again, your test case already passes, so it's not a regression test.

[hamidrezaghavami]

@ljharb To clarify my intent: this patch is a performance early exit fast path inside isBelowBreakLength when breakLength === Infinity, avoiding unnecessary string width calculation loops. Because observable output is identical to main, standard tests pass on both branches. Should we label/track this strictly as a performance optimization/cleanup rather than a bug fix?

[ljharb]

ahh ok, that wasn't clear to me before

[hamidrezaghavami]

@ljharb The CI checks are fully green! I had to force-push one last time to shorten the test string to pass the 80-character max-len linter rule. Could you re-approve when you have a moment, so we can get this merged?
Thank you

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/74874/