Isn't this an entire class of problems that's avoidable by using strict DDD-style entities?
You don't have the same "purists" OOP problems, you don't have extension methods to get lost in, you don't have publicly mutable state, and you have a clear surface area for state changes. And your ORM is happy.
Purists OOP has all sorts of issues, more procedural, pragmatic, approaches can alleviate that pain. And strict entities provide the same surface area as the functional approach, without concerns over breaking ORM tracking. With the added benefits of closely guarding local state.
Opinion time.
This is less "what you can't do in OOP" and more "what you can't do if you use OOP design as dogma" ๐ค. Perhaps that's an important distinction to make, depending on your viewership, but to me this feels like a solution looking for a contrived problem.
If you're trying to build a company then stop using Blazor, and start using react/vue...etc for your frontend and make an Asp.Net API.
If you need a web app, then use well known technology to do it. Otherwise you're just playing in the sandbox, not building something that can be built quickly, and can be easily onboarded to.
So many C# devs are scared of FE tech, learning how to use it effectively will only make your work better, and speedier.
Essentially, use boring technologies and be pragmatic.