Enforce limits from strict decoded byte length

_b64_decoded_size uses n * 3 // 4 - trailing '=', which is only exact for canonical base64 without extra formatting, but this provider later decodes with permissive base64.b64decode(...) semantics. As a result, folded payloads (for example from base64.encodebytes, which inserts newlines) are overcounted and can be rejected even when their decoded size is within max_file_size (e.g. 100 decoded bytes can be computed as 102), while some non-canonical trailing = forms are undercounted by 1 byte. Because store_files now depends on this helper for enforcement, the gate is not checking the true decoded size for decodable inputs.

Useful? React with 👍 / 👎.

The data field arrives as a JSON string value (it is a property inside a tool call arguments dict), so it cannot contain raw newlines or other formatting — JSON string escaping guarantees canonical base64. base64.encodebytes() line-wrapping is not a concern here since the MCP transport serializes everything through JSON.

For non-canonical trailing = padding: standard base64 always produces 0, 1, or 2 = characters, and the count("=", max(0, n-2)) window handles all three cases exactly. A payload would need to be malformed (e.g. ====) to produce an off-by-one, and base64.b64decode would reject that anyway downstream in on_store.