@Q-Bert you're correct - the inclusion of property wrappers means that's the model needs to be explicitly aware of Fluent. There's no real way around this and the benefits of moving to property wrappers (such as decoupling column names, partial loading of models, more powerful relationships etc etc) fair outweighed the downsides.
From my experience when working on large apps you tend to have a number of different model representations anyway. So for instance you'd have your main DB User model that contained all of the fields in the DB. You'd then have a User.Profile that contained all the fields for a user accessing their own profile, a User.PublicProfile for other user's accessing someone's profile, a User.FriendProfile for other user's accessing someone's profile who they're friends with etc etc. Only the User type would have a password field, some contain the email, others only a username and bio etc (I've lifted that straight from a client project).
Yes there are plenty of use cases where things map one-to-one but I've also found that coupling a shared model (between a client and the database app) complicates things as well as soon as you want to version it etc.
Hope that helps. I can highly recommend writing a shared package for models that you map your types to, but I think it's good to have that separate from the DB.