fix: reduce window for multiprocessing race

[jmartin-tech]

#1414 exposed an underlying race condition when using multi-processing capable generators, that are stored in a probe, on the primary execution thread. Serialization leaves the generator in a state that requires client connections to be rebuilt and usage of locks to guard _call_model would introduce further issue in serialization for multiprocessing actions.

By storing local references to the client objects during inference calls the serialization side-effects are limited to a much smaller runtime window

Further work is needed to remove the race condition fully, this is simply a short term mitigation until a more complete refactor can be designed.

Verification

List the steps needed to make sure this thing works

• Test in combination with the iterative probe probe: Base class for iterative probes and FITD as an example #1414

python -m garak -t nim -n <target model name> --parallel_attempts 32 -p <iterative probe class>

[jmartin-tech]

Future iteration will provide unit testing of this type of race condition, this was deferred at this time in the interest of delivering iterative probe patterns more quickly.

There are likely a number of edge cases related to multi-processing that will pop up as the community starts to exercise more probes techniques that require an LLM during the target inference as may multi-turn techniques often rely on this pattern.