Can we make this an integration test instead of an e2e test (they're so verbose and the snapshots are somewhat hard to review). See

This feels rather fragile if we have to do this for many fixes, and we should explore alternative ways to handle string annotations if this becomes a frequent problem, or consider as an alternative solution for how to store types for expressions in stringified type annotations.

Something I had in mind for a long time and that can also become handy if we ever want to support checking Python embedded in other languages (e.g. Python in Markdown) is the concept of virtual files. r-a has something very similar, where code references actual code in a file OR code generated by a macro. The way they solve this is by having a HIRFile. In our case, HIRFile would be a salsa::Supertype enum over:

#[derive(salsa::Supertype)]
enum HIRFile {
	File(File),
	/// Stringified type annotation, 
	EmbeddedExpression(EmbeddedExpression), 
	/// Python in a markdown file
	EmbeddedBlock(EmbeddedBlock),
}

#[salsa::interned]
struct EmbeddedExpression {
	file: File, // Or HIRFile to support markdown docstring in a python code snippet in a python file?
	range: TextRange,
}

#[salsa::Interned]
struct EmbeddedBlock {
	file: File,
	range: TextRange
}

parsed_module and TypeInferenceBuilder would take a HIRFile as an argument and so would other queries. Obviously, this requires more design work to flesh out the details. E.g., how does this work with looking up the scope? But it expresses the concept of nested ASTs (or even documents) in a more explicit way