fix: include PID in ZMQ routing identity for minion/syndic REQ sockets

[waterWang]

What does this PR do?

Fix a 3006.27 regression where salt-call (and other one-off processes that set __role=minion) collide with the long-running salt-minion daemon on the stable ZMQ routing identity.

Why was this needed?

Commit 36e914a72 ("Use stable ZMQ identity for minion + syndic daemon ret-port REQ sockets") introduced a stable identity per AsyncReqMessageClient:

identity = "salt-req/{role}/{minion_id}/{slot}".format(
    role=_role,
    minion_id=_minion_id,
    slot=next(_REQ_IDENTITY_SLOT),
)

_REQ_IDENTITY_SLOT is a module-level itertools.count() that starts at 0 per process. A running salt-minion daemon and a one-off salt-call both set opts["__role"] = "minion" and share the same minion_id, so both compute the identity salt-req/minion/<minion_id>/0. Because the master's ROUTER socket has ROUTER_HANDOVER=1, libzmq hands the peer slot over to the newcomer and silently drops any reply still in flight to the original owner — causing requests to stall for the full REQUEST_TIMEOUT (~60s) before retrying.

What changed?

Include os.getpid() in the identity string for the minion/syndic branch, so one-off processes never collide with the daemon's identity slots. This mirrors the CLI branch which already uses os.getpid() % 256 as the slot component.

Tests written?

• Yes
• No (identity generation is exercised by existing functional transport tests; the change is additive to the identity string format)

Commands signed with GPG?

• Yes
• No

Fixes #70127

[twangboy]

please create this against the 3008.x branch. Also, this will need a changelog and tests