Changelog: say what scaleRounding is, in two sentences (#1753)

The entry ran to four sentences and 756 characters, twice the length of
anything near it, and still never said the thing a reader needs first: that
this is a new optional application setting whose default changes nothing.

Leads with that, keeps the one clause that says why anyone would reach for it,
and drops the worked example, the browser-to-browser comparison and the
device-pixel detail. The first two now live in the display and scaling skill,
alongside the table of what integer scaling actually costs, and the last is a
correctness property a reader cannot act on, pinned by a test instead.


Claude-Session: https://claude.ai/code/session_01NGvtaUNATVCVxD2qcbiY4t

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: obiot

packages/melonjs/CHANGELOG.md

@@ -3,7 +3,7 @@
 ## [20.9.0] (melonJS 2) - _2026-10-18_
 
 ### Added
-- **`scaleRounding`**: `"integer"` constrains the automatic scale factor to a whole number of device pixels per source pixel, letterboxing whatever is left over, where the default `"fractional"` fills the container exactly. A 480 wide design in a 1280 wide container is scaled by 2.667, so some source pixels cover three device pixels and some cover two, which pixel art shows as uneven stems and shimmering edges and which browsers resolve differently, so the same scene looks crisp in one and soft in another. The rounding is applied in DEVICE pixels, since `devicePixelRatio` would otherwise put the fraction back. It affects `scaleMethod: "fit"` only, because every other method resizes the renderer to its container and so has no fixed factor to round
+- **`scaleRounding` application setting**: optional, and `"fractional"` by default, so nothing existing changes. `"integer"` constrains the automatic scale factor to a whole number of device pixels per source pixel and letterboxes the remainder, which is what stops pixel art showing uneven stems and shimmering edges; it applies to `scaleMethod: "fit"` only
 - **Sprite-sheet particles** (`framewidth`, `frameheight`, `frames`, `randomFrame` on `ParticleEmitter`): a particle plays a frame sequence once over its own lifetime, or holds one frame picked at random when it is born. One sheet is one image, so a burst of varied debris still batches into a single draw call ([#1610](https://github.com/melonjs/melonJS/issues/1610), thanks @snowyukitty)
 - **`slerp(v, alpha)` on all four vector classes**: interpolate along the ARC between two directions at a constant angular rate, where `lerp` slows at the ends and shortens the vector through the middle. 2D takes the shorter way round, and the same and opposite cases are handled rather than returning `NaN`
 - **`Trail3d`**: a fading, tapering ribbon that recedes properly into a 3D scene, for an exhaust streak, a speed trail or a spell arc. It is a `Mesh`, so unlike the 2D `Trail` it narrows along its own length, takes a post effect and a `tint`, and costs one indexed draw call rather than a filled path per segment. It needs a `Camera3d` ([#1621](https://github.com/melonjs/melonJS/issues/1621))