update type mismatch errors

[ritvibhatt]

Description

[Describe what this change achieves]

Related Issues

Resolves #[Issue number to be closed when this PR is merged]

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• New PPL command checklist all confirmed.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff or -s.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ No major issues detected

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Add expected types context field Add a context field for expected_types to provide structured information about valid types, similar to other type error patterns in the codebase. This improves error reporting consistency and enables better programmatic error handling. core/src/main/java/org/opensearch/sql/expression/aggregation/SumAggregator.java [87-96] throw ErrorReport.wrap( new ExpressionEvaluationException( String.format( "sum aggregation does not support type %s; expected a numeric type" + " (INTEGER, LONG, FLOAT, or DOUBLE)", type))) .code(ErrorCode.TYPE_ERROR) .context("aggregation", "sum") + .context("expected_types", List.of("INTEGER", "LONG", "FLOAT", "DOUBLE")) .context("actual_type", type.toString()) .build(); Suggestion importance[1-10]: 5 __ Why: Adding expected_types context improves consistency with other error patterns in the codebase (like in ExpressionAnalyzer.java line 281). However, the expected types are already clearly stated in the error message, so this is a minor enhancement for programmatic error handling.	Low
	Add expected argument range context Include expected_arg_range context to specify the valid argument count range (1-9). This provides structured information about the constraint and maintains consistency with other error reporting patterns that include both expected and actual values. core/src/main/java/org/opensearch/sql/expression/function/DefaultFunctionResolver.java [57-65] throw ErrorReport.wrap( new ExpressionEvaluationException( String.format( "%s function expected 1-9 arguments, but got %d", functionName, unresolvedSignature.getParamTypeList().size()))) .code(ErrorCode.TYPE_ERROR) .context("function", functionName.toString()) + .context("expected_arg_range", "1-9") .context("actual_arg_count", unresolvedSignature.getParamTypeList().size()) .build(); Suggestion importance[1-10]: 4 __ Why: Adding expected_arg_range provides structured information about the valid range, which could be useful for programmatic error handling. However, the range "1-9" is already present in the error message, making this a minor improvement for consistency rather than a critical fix.	Low