[Feature]: [P3] Budget the decorative per-frame re-rasters (scaled crane, fountain) on mobile

Deferred from /gds-code-review of the crane rescale (PR #567, spec-crane-scale, review finding E4). Backlog row decorative-raster-budget.

The crane rescale grows its animated re-raster and GPU texture upload 6.25x: the cache: true canvas went from 128x76 (~38 KB RGBA per upload) to 320x190 (~243 KB), re-uploaded every animating frame while the decorative clock runs. The fountain plaza already re-rasters per frame by design (cache: false, owner-approved), so the scene now carries two sizable per-frame texture uploads on phones the codebase documents as freeze-prone.

No player-visible defect is known; this is a measurement-first task:

• Wait for the session_fps field telemetry (#538) or an on-device probe on a low-end phone to price the decorative uploads.
• If they show up in frame health, mitigate: halve the crane's animation cadence (flagDirty every other decorative tick), split static mast/jib from the moving trolley/hook/beacon into layered actors so only a small strip re-uploads, or cap decorative re-raster work at low zoom where the motion is sub-pixel anyway.
• Do not regress the pause/reduced-motion freeze semantics (repaint fully stops today) or determinism under the stepped screenshot clock.

Not a blocker for the crane PR: the cadence is unchanged, only the payload grew, and the fountain precedent stands until data says otherwise.

Start with the session_fps telemetry from #538 or an on-device probe on a low-end phone, then measure the crane and fountain's per-frame raster uploads. Compare the results with the existing pause, reduced-motion, and stepped screenshot-clock behavior; done means a data-supported mitigation that preserves freeze semantics and determinism.