I think your questions arise from the architecture you propose. One big concern about your solution is encapsulation: who does what?

The repository pattern should abstract the data access layer to the consumer. So the consumer is essentially telling the interface: I want you to update this entity in the database, how you do that is none of my business.

But in your implementation you assume that the object returned by FindById is EF tracked and therefore can track changes in your MVC controller. This is a leaky abstraction.

If we don't follow this logic, FindById will return an entity that is not tracked by EF. The entity will be updated in the MVC controller and then the repository's Update function will update the latest version in the DB.

How do you do that? Well, in most cases you don't track domain entities in EF, you create a special database DTO used for that purpose (here more details).

However, if you don't want to do that, the repository pattern is not the only architecture that can be used to solve these kinds of problems. Try looking at the following talk.