chore(msg-sim): expose next peer id, naming of worker threads

[thedevbirb]

For profiling purposes, is helpful to expose the next peer id that will be used when adding a peer. For example, one could create custom os thread names to reflect it, simplifying visualization. The default runtime factory reflects this.

[claude]

Code Review - Issue Found

Incorrect thread naming when creating multiple PeerOptions ahead of time

Location: msg-sim/src/network.rs:234

The default_runtime_factory() captures the next peer ID at factory creation time via next_peer_id(). However, when multiple PeerOptions::default() instances are created before any are consumed by add_peer_with_options(), they all capture the same peer_id value because PEER_ID_NEXT is only incremented at the end of add_peer_with_options().

This causes thread names to show incorrect peer IDs, which defeats the stated profiling purpose of this PR.

Example:

let opts1 = PeerOptions::default(); // captures peer_id = 1
let opts2 = PeerOptions::default(); // captures peer_id = 1 (still not incremented)
let peer_1 = network.add_peer_with_options(opts1).await; // actual peer_id = 1
let peer_2 = network.add_peer_with_options(opts2).await; // actual peer_id = 2, but threads named 'peer-1-w*'

Note: The typical usage via network.add_peer().await is unaffected because PeerOptions::default() is called inline immediately before the counter is incremented.

Suggested fix: Instead of capturing the peer ID at factory creation time, consider passing it as a parameter when the factory is invoked (inside add_peer_with_options() after the actual peer ID is determined), or document this limitation in the PeerOptions::default() documentation.

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.