Inconsistent use of transfer instead of safeTransfer in stMAT operations enables silent failures

In the claimAndMintStMAT function of the GenesisLicenseStaking contract, the code uses the standard transfer method instead of safeTransfer when sending stMAT tokens to users:

stMAT.transfer(msg.sender, stMATAmount);

This contrasts with other parts of the contract where safeTransfer is consistently used for token transfers, such as in the claim function:

IERC20($._mat).safeTransfer(msg.sender, totalAmount);

The use of transfer instead of safeTransfer creates a potential risk if:

1. The stMAT token does not follow the standard ERC20 implementation (for example, returns false on failure instead of reverting).
2. The stMAT contract is upgradeable and its behavior changes in the future.
3. The stMAT address is changed to point to a non-standard token implementation.

If any of these scenarios occur, failed transfers would not revert the transaction but would silently fail, potentially leading to users not receiving their tokens while the contract state is updated as if the transfer succeeded.

A silent transfer failure desynchronises on-chain accounting from actual user balances. The contract would record the claim as fulfilled while the user receives nothing.

Replace the direct transfer call with safeTransfer for consistency and to prevent silent failures:

// Replace this:
stMAT.transfer(msg.sender, stMATAmount);

// With this:
IERC20(address(stMAT)).safeTransfer(msg.sender, stMATAmount);