[False-Positive]: arbitrary-send-erc20 fires on EIP-712 signed order patterns

## Description

The \rbitrary-send-erc20\ detector fires on \ ransferFrom(signedOffer.maker, ...)\ even when \offer.maker\ is not attacker-controlled — it is the signer of a validated EIP-712 offer.

## Reproduction

In 3FLabs/grunt (\Request.sol#consume\):

\\\solidity
function consume(Offer calldata offer, bytes calldata signature, uint256 ptAmount)
external
onlyOwnerOrRoles(_ROLE_CONSUMER) // access-controlled
nonReentrant
returns (uint256 ytAmount)
{
_validateOffer(offer, signature); // EIP-712 signature check
// ...
_asset().safeTransferFrom(offer.maker, address(this), ptAmount); // <-- flagged
}
\\\

Slither flags this as High-severity because \offer.maker\ is passed as the \rom\ argument. But:

1. The offer is EIP-712-validated — \offer.maker\ signed the offer and authorized the exact transfer
2. The function is access-controlled (\onlyOwnerOrRoles(_ROLE_CONSUMER)\)
3. The maker cannot be overridden by an attacker — they signed the struct hash

## Why this is a false positive

The \rbitrary-send-erc20\ detector was designed to catch cases where an attacker can pass an arbitrary \rom\ address to drain tokens from any account that approved the contract. In this pattern, the \rom\ is fixed by the offer signature — the maker explicitly authorized the transfer by signing.

This is a widely used pattern in DeFi (similar to Seaport, 0x protocol, Morpho intents). The detector has no concept of EIP-712 authorization and incorrectly treats signed makers as attacker-controlled.

## Impact

Every DeFi protocol using signed order books, intent-based execution, or EIP-712 offers gets High-severity false positives from this detector.

## Environment

- Tested on 3FLabs/grunt (https://github.com/3FLabs/grunt)
- Full analysis: https://github.com/holistis/bug-bounty-intelligence-mcp/blob/main/BENCHMARK.md

Reproduce the warning on 3FLabs/grunt's Request.sol#consume, focusing on _validateOffer and the safeTransferFrom(offer.maker, ...) call, then inspect Slither's arbitrary-send-erc20 detector. Done means validated EIP-712-signed makers no longer produce this false positive while genuinely attacker-controlled from addresses remain detectable.

Written by the indexing model from the issue text.