Summary

• replace stepCommand('restart') with command('restart') in:
  • test/parallel/test-debugger-restart-message.js
  • test/parallel/test-debugger-run-after-quit-restart.js
• in test-debugger-restart-message, wait for Debugger attached. and prompt before asserting the listening message count
• in test-debugger-run-after-quit-restart, continue to assert behavior via waitForInitialBreak() and breakInfo

Context

test-macOS has shown intermittent timeouts while waiting for BREAK_MESSAGE in restart-related debugger tests.
In failing logs, reconnect succeeds (Debugger attached. is printed), but the expected break ... in line is not observed before timeout.

Hypothesis

The flake is likely caused by a timing race in CLI output ordering around restart/reconnect:

• stepCommand() requires BREAK_MESSAGE to appear
• under some timing conditions (seen on macOS unusual-path runs), attach/prompt output arrives, but break ... in output is delayed or missed by this wait pattern

This change does not claim to prove a single root cause. It may be related to timing behavior in test/common/debugger.js, but this PR only narrows these two tests to a less fragile synchronization path aligned with what each test is actually verifying.

Why this approach

• keep test intent intact
• reduce dependence on a brittle BREAK_MESSAGE wait specifically for restart
• minimize blast radius by changing only the affected tests

Testing

• out/Release/node test/parallel/test-debugger-restart-message.js
• out/Release/node test/parallel/test-debugger-run-after-quit-restart.js
• additional stress checks were run from an unusual-character path with reduced timeout settings

Fixes: #61762