New parser deviates from old parser in edge cases with function type comments

[ilevkivskyi]

This is a follow-up for #21823. Most notably we get a false negative in situations like this:

class A:
    def f(self):
        # type: () -> None
        def g(x):
            # type: () -> None  # Error not detected: signature has too few parameters
            pass

cc @JukkaL

[abhinav-phi]

I'd like to pick this up — unless you're planning to handle it as part of the native-parser work in #21823, in which case happy to stand aside.

Understanding

With the new parser enabled, a function carrying a function-type comment that disagrees with its actual signature is no longer diagnosed. For the reported one-liner, the old parser flags the nested def's # type: () -> None comment as mismatching the annotated parameter, while the new parser silently accepts it (false negative). So this is a parser-parity regression in the type-comment validation path, freshly exposed by the parser default flip.

Plan

1. Add a testdata case (under the check-functions tests, or wherever function-type-comment diagnostics are grouped) that pins the expected error for the reported snippet, including the nested-function case.
2. Restore the signature-compatibility check for function type comments in the new parser, so parameter count/type mismatches are diagnosed exactly as the old parser did.
3. Run the full test suite plus mypy self-check; if anything interacts with the migration machinery around Make native parser the default #21823 I'll call it out in the PR.

I'm starting now and will open a PR within the next couple of days.

[ilevkivskyi]

@abhinav-phi Just to save you some time:

• We do not accept LLM generated PRs from new contributors, see https://github.com/python/mypy/blob/master/CONTRIBUTING.md
• Fixing this issue needs good understanding of mypy architecture, so I am not sure it is a good first issue.
• Most of the work for this issue would be done in https://github.com/mypyc/ast_serialize