Pyright hangs/fails opaquely on large codebase

Nobody has claimed this yet.

I am/was running into #10910 with the monolithic `types.py` file that `prisma-client-py` generates. Past a certain number of statements, the exported types are inferred as `Unknown` and type checking breaks in various places because of it.

So I tried this, as suggested by @erictraut:
> If you want this to work with pyright, you'll need to reduce the complexity by breaking it into multiple modules. Since it's auto-generated, it should be straightforward to modify the generation script so it generates multiple submodules rather than one ginormous module.

_{PR: https://github.com/Significant-Gravitas/prisma-client-py/pull/1}

What I did was split up prisma.types into one file per DB model. These files still have relations between them, but I've amended the generator to only import sibling modules that are actually referenced by the current module.

The result: rather than refusing to analyze, Pyright now *hangs* trying to analyze dependent modules, with no clear sign why or what the exact problem is.

It looks like the total complexity of our codebase is tripping up Pyright, with some modules' dependency graph being just too large (e.g. `backend.data.graph`) so they cause a hang when analyzed individually, and some just small enough it still works (e.g. `backend.data.onboarding`). This also means I can't really provide a minimum reproducible example: that would be our codebase as it currently is.

This is a terrible situation for obvious reasons. Static type checking is an important part of how we catch and prevent breakage before it happens. The type checker - apparently - has limitations and it isn't clear how we can amend our project to stay within those limitations.

It would be immensely helpful if:
- Pyright could log verbosely enough that I can see where/why it is hanging
- Pyright would emit a message stating its refusal to analyze a module that exceeds one of its limits
- Pyright could be configured with higher limits
- Pyright's limits came with clearer instructions on how to stay within them

None of these things are the case, and it leaves me with no clear path to resolve the problem I'm having.

@erictraut Could you help us fix this? I'd be happy to contribute to Pyright, but right now I have no idea where to even look regarding this issue. Please let me know your thoughts and how I can help.

_Originally posted by @Pwuts in [#10910](https://github.com/microsoft/pyright/issues/10910#issuecomment-3757262374)_

Use the monolithic generated `types.py` and the split modules described in prisma-client-py PR #1 as the reproduction case. Start by reproducing the hang around the dependent modules `backend.data.graph` and `backend.data.onboarding`, then trace what Pyright reports while analyzing them. Done means the failure is diagnosable through clear logging or an explicit limit message, with any supported configuration documented.

Written by the indexing model from the issue text.