Extension methods are a way to add functionality to existing classes or interfaces without modifying their source code or creating a subclass. For example, you can define an extension method for the String class that reverses the characters in a string, and then use it as if it was a regular method of the String class.
Taking that information into consideration, you should treat the extension as part of the class, to which that extension extends. In other words, keeping SRP in mind, for every component, that has an extension, there will be a separate corresponding "extensions method folder".
However, you might use extension methods to implement data mappers. In that case, we will follow instructions provided by Uncle Bob in his book "Clean Architecture: A Craftsman's Guide to Software Structure and Design". I will quote the whole chapter, it is very short:
DATA MAPPERS
Going back to the topic of databases, in which layer do you think ORMs like Hibernate belong?
First, let’s get something straight: There is no such thing as an object-relational mapper (ORM). The reason is simple: Objects are not data structures. At least, they are not data structures from their users’ point of view. The users of an object cannot see the data, since it is all private. Those users see only the public methods of that object. So, from the user’s point of view, an object is simply a set of operations. A data structure, in contrast, is a set of public data variables that have no implied behaviour. ORMs would be better named “data mappers,” because they load data into data structures from relational database tables.
Where should such ORM systems reside?
In the database layer of course.
Indeed, ORMs form another kind of Humble Object boundary between the gateway interfaces and the database.