Don't generalize capturing lambdas in argument position

[rtfeldman]

Closes #9699.

A static-dispatch method chain on a value whose type is not yet concrete — such as letters.to_utf8().contains(...) where letters is a string literal flowing through find_first — could report a spurious MISSING METHOD: ... on an unresolved type variable error. The cause was that a capturing lambda passed directly as a call argument was being generalized at its own rank, before the caller pinned its parameter types. That froze the lambda body's static-dispatch chain as a generalized scheme; when the predicate was then instantiated, only the instantiated copy's dispatches got resolved against the concrete element type, leaving the original CIR node's type variable an unresolved flex dispatcher that the end-of-check ambiguity sweep then flagged.

A bare (non-capturing) lambda in argument position already skips generalization via the !is_call_arg guard in shouldGeneralize; the closure (capture-wrapper) case slipped through because checkExpr clears the checking_call_arg flag before delegating to the inner lambda. The fix re-asserts that flag in the e_closure case, so a capturing argument lambda is treated the same as a bare one and is not generalized — letting its dispatch chain resolve in place once find_first pins the element type, with the side benefit of creating fewer type variables.