fix(jdk-codemodel): resolve implicit lambda parameter types

[deer]

LambdaParameter.type was non-optional, so implicit lambda parameters ((a, b) -> ...) produced UnknownTypeUsage indistinguishable from a failed resolution of an explicitly-annotated type. This PR fixes that and consolidates the type resolution infrastructure.

Changes:

• LambdaParameter.type is now Optional<TypeUsage>. Optional.empty() means "no annotation and inference unavailable"; Optional.of(type) means resolved (whether from an explicit annotation or javac's inferred type). Lambda marshalling updated to use marshal(null) / Optional.ofNullable(unmarshal(...)) to preserve absence across round-trips.

• JdkExpressionConverter gains resolveLambdaParameterType(VariableTree): explicit params wrap resolveTypeUsage in Optional.of; implicit params resolve via trees.getTypeMirror(TreePath.getPath(compilationUnit, p)).

• A resolveTypeMirror(Tree) → Optional<TypeMirror> helper centralises the null/error-kind TypeMirror checking logic that was previously duplicated across resolveTypeUsage, resolveLambdaParameterType, and resolveReceiverType.

• JdkStatementConverter no longer maintains its own copy of resolveTypeUsage or the trees/compilationUnit/typeResolver fields that supported it. All three call sites now delegate to exprConverter.resolveTypeUsage. setTypeContext removed; the corresponding call in JdkInitializer removed.

• New test shouldResolveImplicitLambdaParameterTypes verifies that (a, b) -> ... params resolve to String when the target type is Comparator<String>. Five existing call sites updated to .type().orElseThrow().