fix(callbacks): bind RPC responses to their source and use unpredictable ids

[Pajt9whauht283as]

Summary

As discussed in #182 — pending client-callback responses were stored keyed only by a sequential, shared counter (name .. N), and the response handler never verified that the responding player was the one the request was sent to. Any connected client could resolve another player's pending callback with forged data by guessing ids.

Changes

• Pending calls are now keyed with random per-call tokens instead of the shared sequential callBackId
• Each pending entry records the initiating source
• ExecuteRpc rejects responses whose source does not match the initiator
• Async/sync dispatch now strictly checks what is actually pending (promise vs callback), avoiding type-confusion if a client tampers with isSync on its own response

No API changes — TriggerAsync / TriggerAwait / Register signatures and behavior are unchanged for legitimate flows.

Fixes #182

[Pajt9whauht283as]

Note for reviewers: no API changes \u2014 \TriggerAsync/\TriggerAwait/\Register\ signatures and behavior are identical for legitimate flows; only id generation, source-binding and dispatch safety changed.

[dop42]

Before outsider review it and potentially merge it, could you put the PR in the repo's template format please, and take a pass on a few review points: cleanup for orphaned TriggeredCalls entries (not sure if this is already handled elsewhere in the code, but wanted to flag it), the duplication between TriggerRpcAsync and TriggerRpcAwait, and the promise variable shadowing the module name.

[outsider31000]

HI, you have failed to use the PR template besides callbacks are not meant to provide security.
They exist to make development simpler by allowing the server and client to exchange a request and response.
If a developer is trusting client-returned data for anything security-sensitive, that is already a problem in their own code.

Security and validation belong in the resource logic. The callback system is not an authentication or anti-tampering layer, and it should not be turned into one.