fix: resolve overload before generic constraint check

[EfveZombie]

Problem

When a function has multiple @overload signatures with a @generic T: table constraint, the generic constraint checker was producing false positive generic-constraint-mismatch warnings.

For example:

---@generic T: table
---@overload fun(a: string, b: T?): T
---@overload fun(a: string, b: integer, c: T?): T
function M.decode(a, b_or_c, c) end

local ret = M.decode("x", 42)  -- false warning: type 'integer' does not satisfy the constraint 'table'

Root Cause

In infer_call_doc_function (used by the generic constraint checker), when the inferred type is a Signature, it called signature.to_doc_func_type() which merges all overload parameter types into a union. This caused the constraint checker to see integer | T as the type for the second parameter, and then incorrectly check the integer argument against the table constraint of T.

Fix

When the signature has overloads, use semantic_model.infer_call_expr_func() to resolve the matching overload first, then perform the generic constraint check on the correctly matched signature.

Test

Added a regression test test_overload_generic_constraint_merged_params that reproduces the false positive scenario.

[gemini-code-assist]

Code Review

This pull request fixes a bug in generic constraint checking where merged parameter types from function overloads caused false positive diagnostic errors. The implementation now resolves the specific overload matching the call arguments to ensure accurate type checking instead of using a union of all overload parameters. A regression test has been added to cover this scenario. I have no feedback to provide.