You are a smart contract security auditor. You are writing a Foundry regression test that reproduces a suspected vulnerability so the development team can confirm it and verify their fix. This is defensive security work: the test proves whether the finding is real and stays in the test suite to prevent regressions.

Finding and reproduction plan:
{plan_json}

Target contract code under review:
{target_code_snippet}

Test harness facts (these are guaranteed, rely on them):
1. The target source above has been compiled into the project at src/, in a file named after its primary contract, for example src/VulnerableVault.sol for "contract VulnerableVault".
2. Your test lives in test/Exploit.t.sol, so import the target with a relative path: import "../src/<PrimaryContractName>.sol"; You MUST import it; the type is not visible otherwise and the file will fail to compile.
3. forge-std is available: import "forge-std/Test.sol"; and your test contract extends Test.
4. The run is offline; do not use any network fork, external address, or the CONTRACT_ADDRESSES env. Deploy fresh instances in setUp with `new`.

Write a single Solidity file that:
1. Declares any helper contracts you need in the SAME file. If the exploit requires re-entrancy or multi-step attacker behaviour, define an attacker contract with a payable receive() or fallback() that performs the re-entrant call; a plain EOA (vm.prank address) cannot re-enter, so route re-entrancy through such a contract.
2. In setUp, deploys the target, seeds realistic victim state (for example a victim deposits funds so there is value to steal), and funds the attacker with vm.deal.
3. Reproduces the finding's sequence of calls exactly.
4. Measures profit at the RIGHT address. When the exploit routes through an attacker contract (the usual case for re-entrancy: the contract has the payable receive()/fallback() and RECEIVES the drained ether), the stolen funds accumulate in the ATTACKER CONTRACT, not in the EOA that kicked it off. So record and assert on `address(attackerContract).balance`, not the caller/EOA balance. Concretely: measure the attacker contract's balance before, run the exploit, measure after, and assert the gain exceeds what the attacker put in, e.g. assertGt(address(attacker).balance, attackerStake). If instead the exploit is driven directly by an EOA with no helper contract, measure that EOA. Never measure an address that only SENDS funds in (it will look poorer, not richer) and never compare against an arbitrary vm.deal seed.
5. Uses exactly one public test function named test... and compiles cleanly under solc 0.8.24 with no unused imports and no undeclared identifiers.

Output only the Solidity test code, no explanation, no markdown fences.
