#5301: use Expect.Natural in EOresized instead of ad-hoc intValue narrowing

[morphqdd]

Closes #5301.

EOmalloc$EOof$EOallocated$EOresized.lambda() built its own ad-hoc Expect chain for id and
new-size that narrows the Double to int with Double::intValue directly, unlike every other
malloc-related atom in this package (EOmalloc$EOof$EOφ, EOmalloc$EOof$EOallocated$EOread,
EOmalloc$EOof$EOallocated$EOwrite), which all use Expect.Natural. Double.intValue() truncates
fractional values silently and saturates out-of-range values instead of throwing, so
<allocated>.resized 5.7 silently resized to 5 bytes instead of rejecting the non-integer size.

Replaced both ad-hoc chains with new Expect.Natural(...), matching the sibling atoms.

Added a throws-on-changing-size-to-fractional test to malloc.eo, mirroring the existing
throws-on-changing-size-to-negative test, covering the fractional-size case that the ad-hoc
chain didn't validate.

Ran the full EO-generated malloc test suite locally (EOmallocEOAtomTest) — all 36 tests pass,
including the new one.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🚀 Performance Analysis

All benchmarks are within the acceptable range. No critical degradation detected (threshold is 100%). Please refer to the detailed report for more information.

Click to see the detailed report

Test	Base Score	PR Score	Change	% Change	Unit	Mode
benchmarks.XmirBench.xmirToEO	13381.355	13174.753	-206.602	-1.54%	ms/op	Average Time

✅ Performance gain: benchmarks.XmirBench.xmirToEO is faster by 206.602 ms/op (1.54%)

[morphqdd]

@yegor256, please take a look when you have a moment.

[0crat]

@morphqdd Thanks for the contribution! You've earned +12 points for this: +16 as a basis; -4 for too few (18) hits-of-code. Please, keep them coming. Your running score is +500; don't forget to check your Zerocracy account too).