Fixes #20792

Root cause

try_infer_partial_generic_type_from_assignment in mypy/checker.py
handles inferring the real type of a partial type (e.g. x = []) once
it is assigned a value that determines the generic parameter. It looks
up the partial_types entry for the variable, evaluates the rvalue,
and then deletes the entry from partial_types after recording the
inferred type on the Var.

The bug is that evaluating the rvalue can itself resolve the same
partial type as a side effect. This happens when a walrus assignment
inside a comprehension in the rvalue reassigns the very same
partial-typed name, e.g.:

errors = []
errors = [
    i for i in (1, 2, 3) if (errors := [1])
]

Here, evaluating the outer rvalue (the list comprehension) triggers
type-checking of the inner walrus assignment errors := [1], which
recurses back into try_infer_partial_generic_type_from_assignment
for the same Var, resolves its partial type, and deletes it from
partial_types. When control returns to the outer call, it tries to
delete the same (now-missing) entry again, raising KeyError.

Fix

After evaluating the rvalue, check whether the variable is still
present in partial_types before proceeding to finalize/delete it.
If a nested assignment (such as the walrus above) has already resolved
it, there is nothing left to do.

Testing

• Added a regression test testWalrusPartialTypeShadowedInComprehension
  in test-data/unit/check-python38.test, matching the minimal repro
  from the issue (courtesy of @ilevkivskyi).
• Confirmed the new test crashes with the same KeyError on
  mypy/checker.py without the fix, and passes with it.
• Ran the full check-python38.test file (61 tests) plus all
  Walrus/Partial-related tests across testcheck.py (198 tests) —
  all pass.
• Manually verified mypy no longer crashes on both the minimal repro
  and the original real-world repro from the issue, and that the
  inferred type of errors is now list[int] as expected.