Does process.call in gleam/erlang/process ever cancel the callee, or only stop the caller waiting?

Timeout semantics of process.call

I'm designing a Gleam service on the BEAM target that makes blocking requests to worker processes using process.call from gleam/erlang/process with a timeout in milliseconds. My understanding from the module documentation is that when the timeout elapses, the caller gets a timeout outcome instead of blocking forever — but the callee keeps running and may still deliver a late reply.

That raises a design question I can't resolve from the docs alone: if I reuse the same subject for subsequent calls, a stale reply from an earlier timed-out call could sit in my mailbox and be misread as the answer to the next call. The documented alternatives for real cancellation seem to be process.kill or monitoring/linking, which are explicit and abrupt rather than timeout-driven.

My constraints: I want graceful degradation on slow workers, no cross-contamination between sequential calls, and ideally no orphaned workers burning resources after their caller has given up.

Specifically:

• Is a fresh subject per call the intended way to avoid late-reply confusion, or is there a documented flush/selective-receive pattern?
• Is there any supported mechanism where a timeout also signals the callee to stop, or is protocol-level shutdown messaging the only clean option?
• Do these behaviors differ meaningfully across recent gleam/erlang releases I should pin against?