(test): pin the own pid in the procstart batch tests (#426)

[devsuitup]

Closes #426

Cause

test/cli-session-procstart-batch.test.js boots cli-session-state without pinning ownPid. init() defaults it to process.pid (cli-session-state.js:126), and ownProcessFilter / descendsFromThisProcess (cli-session-state.js:63-70, 357) exclude any descriptor whose pid equals it. The two failing tests write descriptors for pids 1000..1066. On a Windows runner the test process's own pid can fall in that range, so one candidate is treated as "ours" and removed from the result: 2 instead of 3 on the Windows-cap test, 66 instead of 67 on the Linux-branch test. A rerun gets another pid and passes. Not a production bug: excluding the app's own process is intended.

Proof

Forcing process.pid with a --require preload on the unmodified test:

• pid 1066 and 1010: both tests fail (2 !== 3, 66 !== 67).
• pid 4242: the other tests using 4242 fail too.
  With ownPid: -1 in the test's init calls, both tests pass for pids 1066, 1010, 1000 and 4242 (only the unrelated real-creation-time test fails under a faked pid, as expected).

Fix

Test only: pass ownPid: -1 in boot() and in the "no probe is spawned" test.

Runs

30/30 green of the file under Node 22 + c8. task check: 119 pass, 0 fail, 1 skipped.

[devsuitup]

Review at 78803a9: 0 blocking. The root cause holds. init() defaults ownPid to process.pid (cli-session-state.js:126), and the own-process filter drops a descriptor with that pid. The tests write pids 1000-1066, so a runner pid in that range drops one candidate. Forcing process.pid to 1066 or 1010 reproduces 2 !== 3 and 66 !== 67 on the old test. ownPid: -1 is truthy, so it passes the || default. The change is test-only, and the production exclusion is intended.