feat(perps-controller): add scaleSkew to Scale orders

[abretonc7s]

Explanation

Adds optional size weighting to Scale orders with OrderParams.scaleSkew.

• Rung weights ramp linearly from 1 at scaleMinPrice to scaleSkew at scaleMaxPrice for both buys and sells. Values above 1 put more size near the maximum price; values below 1 put more near the minimum.
• Omitting scaleSkew, or setting it to 1, preserves the existing even split exactly.
• splitScaleSizes accepts the same optional skew so client previews and submitted orders use one allocation algorithm. It allocates whole size-grid units with deterministic largest-remainder rounding, and the rung sizes always sum to the requested total.
• Non-finite and non-positive values are rejected before signing with the existing ORDER_SCALE_RANGE_INVALID code. Reusing this code keeps the exported PerpsErrorCode union backward-compatible.
• A skew that creates a zero-size or below-minimum rung is rejected before the batch reaches the exchange.

The new fields are optional, so existing Scale orders and all other order types are unchanged.

Validation

• Full @metamask/perps-controller test suite passes.
• Targeted Scale/strategy suites: 3 suites, 212 tests passed.
• mm-harness recipe: 6/6 nodes passed, covering calculation, validation, provider submission, and public exports without a setup shim.
• Changed-file ESLint and Prettier checks pass.
• Changelog validation passes.

The installed harness metamask.perps.place_order action does not yet expose Scale parameters, so the recipe provides deterministic provider-level integration proof rather than a live signed testnet placement.

References

• TAT-3817
• Unblocks TAT-3812 Mobile Scale-order UI work.

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Changes how scale order sizes are allocated before they are signed and submitted. The even-split path is preserved, but incorrect skew math would place a different ladder than the caller previewed.

Overview
Scale orders can now weight size along the price ladder via optional OrderParams.scaleSkew, instead of always splitting evenly.

Weights ramp linearly from 1 at scaleMinPrice to scaleSkew at scaleMaxPrice for both buys and sells. Omitted or 1 keeps the existing even split (leftover on the first rung). Skewed allocation floors each rung in size-grid units and gives leftovers to the largest discarded fractions (ties by index). splitScaleSizes is the single source of truth so client previews match placement.

Invalid skews (<= 0 or non-finite) and skew on non-scale types are rejected before signing (ORDER_SCALE_RANGE_INVALID / ORDER_STRATEGY_PARAMS_NOT_SUPPORTED). A skew that zeros a rung or drops a rung under the venue minimum is refused with the existing size/notional errors.

^{Reviewed by Cursor Bugbot for commit 14f5cd0. Bugbot is set up for automated code reviews on this repo. Configure here.}