I suppose you would have some logic deciding what actual "however you decide to call it" to use. So, "a client need to get a list of products from somewhere". Well, give it a "List". The client does not know from where the "List" comes from, it just knows that it recieves a "List".
However, if we are talking about an object from where you can pull entities or pull lists of entities then we need another name... perhaps an "Iterator"?
Now, perhaps you want to abstract from where you get the "List" or the "Iterator". In that case, I would argue that it is a "Database Connection" (note: database does not imply relational, nor persistent).
However, you could be thinking of an "Adapter", that is an object that converts an inconvenient interface into one easier to use. In this case, it is converting the inconvenient interface of the actual data source to something you can use without worrying about it. For instance, if an application can work with different database engines, it will have an adapter for each one.
From the words you have, I would call it "Source". By making analogy with "DataSource", as an object from where the client code can retrieve entities without worrying for where they actually come.
About the other words you have, "Storage" would suggest that you can store there. And for "Reposity" I would expect a reperesentation of the place where the data is stored. I would expect it to have information about that place.