onServerPrefetch causing unstable ids from useId, leading to hydration mismatches

[YaredFall]

Vue version

3.5.10

Link to minimal reproduction

https://play.vuejs.org/#__SSR__eNp9klFLwzAUhf/KNU8buE5RX3QKKgr6oKKCLwEZ7d2W2SYhN90Gpf/dm3Td5ph9a845ab7knkrcWpssShSXYkSpU9YDoS/tjdSqsMZ5eDQGJs4UIEUy5EVIS7Gxv5SfvTmcoE9n29yu2m4YDZsD+Ne88FjYfOyRVwCjo8EA/EwRLN3YWnRQIBESlBZURmBcxprRzOYW/AWDQbNv95yosBaAh439h6ORWnc03CEQx8JTavRETZM5Gc2vUYW0FKkprMrRvVqvjCYpLiE6wRvnuVk+R827Eo9bPZ1h+nNAn9MqaFIwUbyIFBvPj90UfWM/fLzgir83ZmGyMud0h/mOZPIyMDaxu1JnjL2Ti7RPcWhKTz/pYeVRU3upABqSdcxLwTO777j6FvcsOY/7pK75Fdf9+L9NFZSETxnUbVfW5eDHJ8+zhusm0OtfdTcmU4v1wFXGYJXKamYIM2+c/fnuN7ID0eiPWLM2vs8q9X6i1+vD9Q1Udb8bmnLjD7bvm38WZsFUZ8lFcnoi6l+a+TcK

Steps to reproduce

1. Open SFC Playground
2. Make sure that SSR is turned ON
3. Notice that there is an hydration mismatch error (reload page if it's not shown immedeately)

What is expected?

No hydration mismatch caused by unstable ids

What is actually happening?

When the onServerPrefetch hook is used in a component, all of its children useId hooks seems to be delayed while rendering on server.

For example, imagine you have 2 sibling components.
These components using useId() composable to generate id.
They will get ids v-0 and v-1 in the order of render both on client and server. Everything is fine.

Lets wrap first component with a wrapper that uses onServerPrefetch hook.
Now components will following ids:

• v-1, v-0 on the server
• v-0, v-1on the client

Thus, the order of the ids is different between server and client, which leads to hydration mismatch.

System Info

System:
    OS: Windows 10 10.0.19045
    CPU: (12) x64 12th Gen Intel(R) Core(TM) i5-12400
    Memory: 16.92 GB / 31.78 GB
  Binaries:
    Node: 20.15.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.7.0 - C:\Program Files\nodejs\npm.CMD
    pnpm: 9.7.1 - C:\Program Files\nodejs\pnpm.CMD
    bun: 1.1.23 - ~\.bun\bin\bun.EXE
  Browsers:
    Edge: Chromium (127.0.2651.86)
    Internet Explorer: 11.0.19041.3636
  npmPackages:
    vue: latest => 3.5.10

Any additional comments?

No response