Potential Cache Bug in Daemon Mode with Passed-in String Code

Bug Report

I encountered a potential caching issue when using dmypy to type-check in-command code string. The issue arises when executing commands with dmypy run -- -c <code>. As shown below, the second command should not produce an error, as the assignment is correct (int to int). However, it seems like the daemon is caching the previous state incorrectly, leading to an error.

I understand that using dmypy in this manner is not typical, as it is primarily designed to be a long-running daemon process, which allows to perform type checking more efficiently by caching state. However, the documentation states that "You can use almost arbitrary mypy flags after --", which suggests that this usage should be supported. This might lead to misunderstandings or confusion about the expected behavior when using inline code execution with dmypy. Additionally, any tooling that leverages the -c option in dmypy for inline type checking will be impacted by this behavior, potentially causing issues in automated workflows and integrations.

To Reproduce, and Actual Behavior

$ dmypy run -- -c "a:str=1"
<string>:1: error: Incompatible types in assignment (expression has type "int", variable has type "str")  [assignment]
Found 1 error in 1 file (checked 1 source file)

$ dmypy run -- -c "a:int=1"
<string>:1: error: Incompatible types in assignment (expression has type "int", variable has type "str")  [assignment]
Found 1 error in 1 file (checked 1 source file)

Expected Behavior

$ dmypy run -- -c "a:int=1"    # second time
Success: no issues found in 1 source file

Your Environment

• Mypy version used: 1.13.0
• Python version used: 3.12.3

Start by reproducing the two dmypy run -- -c commands from the issue with mypy 1.13.0, then trace the dmypy handling of passed-in string code and its cache state. Done means the second command reports success instead of retaining the first command's type error, with regression coverage for sequential inline checks.