Describe the bug

When spawning new isolates at the start of an application, these isolates are mistakenly viewed as "paused on entry" in the call stack of the debugging view.

import 'dart:async';
import 'dart:isolate';

void main() async {
  final isolates = <Isolate>[];

  for (var i = 0; i < 10; i++) {
    isolates.add(await Isolate.spawn(
      (_) {
        print('isolate $i started');
        Timer.periodic(const Duration(minutes: 10), (_) {});
      },
      null,
    ));
  }

  await Future.delayed(Duration(seconds: 2));
  print('at resumed state');
  Timer.periodic(const Duration(minutes: 10), (_) {});
}

Setting a breakpoint on the print in line 18 and running this Dart program in VS Code will show most isolates as "paused on entry" (usually all of them, but not always. Maybe this is a race condition?).
Unfortunately, this is not just a cosmetic issue. It also affects the pause button in the button bar of the debugger, which will now interact with the new isolates instead of pausing / resuming the main isolate like it usually would.

Expected behavior
The isolates (except for main paused on a breakpoint) are all running and should be displayed as such.

I've attached a VM service to print the isolate's state shortly after hitting the breakpoint, the isolates are listed as running there. So I think this may be an issue in the extension (as opposed to something in the vm service).

Screenshots

Immediately after program start, all secondary isolates are shown as "Paused on entry". Then afterwards they're showing up as "".

Please complete the following information:

Dart Code extension: 3.102.0
Flutter extension: 3.102.0 (not activated)

App: Visual Studio Code
App Host: desktop
Version: mac 1.96.3

Workspace type: Dart (LSP)
Workspace name: vscode_startup_issue

Dart (3.6.1): /opt/homebrew/Cellar/dart/3.6.1/libexec
Flutter (3.27.2): /Users/simon/fvm/versions/stable (No device)