How many DbContext Classes Should I have?

Question

Here's what I'd like to know.

Assumptions:

1. It's the year 2020, and not 2010
2. One database containing all relevant entities
3. One web API
4. Using Entity Framework

The question:

Is it typically considered best practice to break EF entities into...

1. A separate DbContext (and Repository) for each entity?
2. One DbContext to rule them all?
3. Something in between?

Is performance, maintenance and/or unit testing affected one way or the other? This being, practically speaking, my first rodeo, I'm unsure of the ramifications of my choice and would appreciate input from others who've been further down this road.

I'm asking this question today because I've got a dozen lookup tables whose data will rarely be edited. It's starting to feel like overkill to have a separate DbContext for each.

I could just throw those entities under the same context used by the table they supply look-ups to.

Or I could do even more, and pull a dozen related entities under the umbrella of a single DbContext.

Or I could just stuff literally the entire database into one DbContext.

And I cannot tell if there is a right or wrong answer or even if it matters in practice.

I found a number of related questions, but they were either asked a long time ago or weren't the same question. (In particular, I am not asking about what scope to use, as this answer is, I believe, a good one.)

I've included below some relevant links that I found thus far.

when-should-i-create-a-new-dbcontext

linq-and-datacontext

use-multiple-dbcontext-in-one-application

how-many-dbcontexts-should-i-have

how-many-dbcontext-subclasses-should-i-have-in-relation-to-my-models