Python Requirement file choice is cached and reused incorrectly

Describe the bug

Description

tryGetRequirementFile() mutates py.pipRequirementsFile, caching the first successful file choice (setup.py or requirements.txt).

Impact

• Handler reuse across multiple fixes or modules may target the wrong file.
• Confusing behavior in multi-module or multi-vulnerability runs.

Suggested Fix

Avoid mutating shared state; resolve the requirement file independently per fix attempt.

Current behavior

Even if a requirements.txt file is listed, it will still mysteriously fail on not finding a pyproject.toml or setup.py on scan. Furthermore, once the handler successfully reads either setup.py or requirements.txt, it stores that filename in shared state. Subsequent fix attempts reuse that cached file path, even if it is no longer correct for later fixes or modules.

Reproduction steps

Run As Is for Python Code

Expected behavior

Each fix attempt should determine the correct manifest/requirements file for that project context:

• Do not rely on mutable cached state that can leak across fixes/modules.
• If multiple projects are present, selection should be scoped to the relevant project root.
• In short: file resolution should be deterministic and isolated per fix operation.

JFrog Frogbot version

LATEST

Package manager info

PYTHON

Git provider

GitHub

JFrog Frogbot configuration yaml file

DEFAULT

Operating system type and version

ALL

JFrog Xray version

LATEST

Start with tryGetRequirementFile() and inspect how it mutates py.pipRequirementsFile during Python fix handling. Reproduce the scan with multiple modules or fixes and trace which requirement or manifest file is selected. Done means each fix resolves its file independently and selection is scoped to the relevant project root, without shared cached state.