Fix math.round to use HALF_UP to match doc, cel-go/cel-cpp

[rayokota]

Summary

• math.round uses HALF_EVEN (banker's rounding) internally, but cel-java's own function declaration, cel-go's reference implementation, and cel-cpp's reference implementation all specify "ties round away from zero". cel-java is the outlier among the three official reference clients; this PR brings it into alignment by switching the binding to HALF_UP.
• Add four discriminating tie test cases (±0.5, ±2.5). The existing tie cases ±1.5 round to ±2 under both HALF_UP and HALF_EVEN and so could not catch the bug.

Cross-implementation status

Client	Implementation	Spec/stdlib contract	Suite probes a discriminating tie?
cel-go	math.Round(float64(v)) at ext/math.go:629	Go stdlib: "rounding half away from zero"	No (covers 1.5/-1.5 only)
cel-cpp	std::round(value) at math_ext.cc:204	C++ standard: "halfway cases away from zero, regardless of the current rounding mode"	Yes — math.round(42.5) == 43.0 at math_ext_test.cc:552
cel-java (this PR, before)	DoubleMath.roundToLong(x, HALF_EVEN) at CelMathExtensions.java:877	Docstring at L407: "ties rounding away from zero" — but binding does banker's	No (covers 1.5/-1.5 only)
cel-java (this PR, after)	DoubleMath.roundToLong(x, HALF_UP)	Matches docstring + cel-go + cel-cpp	Yes — four new tie cases added below

cel-cpp's test math.round(42.5) == 43.0 is the canonical discriminator: under HALF_EVEN it would round to 42 (since 42 is even) and the test would fail. cel-cpp's suite would catch this bug today; cel-java's and cel-go's
suites would not — both probe only ±1.5, which rounds to ±2 under either mode.