The main issue is that Microsoft moves the core element around (the core system which provides the EDM to the OData system) like it's some kind of small thing but it's not: creating an EDM from mapping/metadata isn't simple. Looking at this page:
https://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/odata-v3/creating-an-odata-endpoint
I see they changed everything as they require an ODataModelBuilder class, to produce the EDM in this particular framework (which is already outdated, as asp.net core again changes everything).
Your example simply passes a Poco with no relationship to the entity to the model builder and of course that doesn't results in proper queries: there's no metadata available at all.
Your route leads to a method 'Get' on a controller which performs a query, but OData is about exposing a model through IQueryable methods, which you can append on with service methods which perform an action, but performing the query you specified in your example, is not how it works: make it a service method (but I have no freaking clue how to do it in the ASP.NET frameworks of today, which might be outdated tomorrow, and it likely already is as the documentation linked above is from 2014) and call that or simply traverse the model exposed by OData, no need for a method like you made (as that looks like a mix of WebAPI and OData)
Sad thing is, the odata support classes model builder we wrote (I think it was the 5th one we had to create for Microsoft's framework-of-the-day) isn't compatible with this one, so can't produce the EDM you want.
So the OData setup you want isn't supported, I'm afraid. The only out-of-the-box support MS delivers is with Entity Framework, as they ship the model builder for that with asp.net.
We analyzed what we should do, as we can't chase after every framework MS releases (as I said, we wrote at least 5 model builders for various frameworks they released during the years, all of them now defunct) and we concluded people will mostly create WebAPI methods, which query the DB based on input and return a resultset, and for the occasional situation where people need OData, they can use WCF Data Services. Other than that, we won't support this OData specific modelbuilder.
I did try to make your example work though, even with DataMember/DataContract attributes, but then it dies in weird errors that it can't serialize parameters (wtf...). So I have no idea to use this. the odata support classes modelbuilder we have can't expose the model so this new service can use it (if only that was true) so that's also not a route to solve it. So unless WCF data services are used, I'm afraid you can't do what you want with our runtime.