feat: Let the length unit be set through initializeForge2D

[spydon]

Description

Box2D has a handful of tolerances that are absolute lengths rather than fractions of the shapes
they apply to. The most visible one is the speculative distance: manifold.c stops generating
contact points past B2_SPECULATIVE_DISTANCE (4 * B2_LINEAR_SLOP, so 0.02 m), and
contact.c sets touching = pointCount > 0, which means beginContact fires while there is
still a gap of up to 2 cm. A world laid out at a much smaller scale than a meter is dominated by
this: shapes that are only a couple of centimeters across are permanently in contact with their
neighbors.

This came up while migrating flame_forge2d (flame-engine/flame#3952), where a reporter's ball had
a radius of exactly 0.02, and it took a week to track down because the 0.02 is not discoverable
from Dart.

Box2D's answer is b2SetLengthUnitsPerMeter, which scales all of them. Its contract is
@warning This must be modified before any calls to Box2D, which a free-standing setter cannot
enforce, so it is exposed through the initializeForge2D gate that already has to run first:

await initializeForge2D(lengthUnitsPerMeter: 100);

• Passing the value already in effect is a no-op, so several games that agree on a scale can each
  ask for it. The comparison round-trips through float32, since that is how Box2D stores it and
  values like 0.04 are not representable in either float width.
• A value that conflicts with the one in effect throws a StateError once a World exists,
  rather than silently corrupting live simulations and the defaults Box2D hands out.
• Non-positive and non-finite values throw an ArgumentError.

Tolerances exposes the derived constants (lengthUnitsPerMeter, linearSlop,
speculativeDistance, aabbMargin), so the 0.02 becomes a documented number that callers can
reason about and assert against instead of a mystery.

The web backend needs a keepalive wrapper: b2SetLengthUnitsPerMeter and
b2GetLengthUnitsPerMeter are plain B2_API functions, so emcc drops them without one.

The README gains a "Units" section covering the scale to lay a world out at, the absolute
tolerances that bite when you do not, and how the other quantities scale when you rescale a world
(lengths, velocities and gravity by S, masses by S², forces and impulses by S³, torques by
S⁴, with densities, friction, restitution and damping unchanged, which leaves the timing of the
simulation unchanged).

Testing

dart test runs suites as isolates that share one process, and therefore one copy of the native
library, so a suite that changes the length unit would be visible to whichever suites run
alongside it. dart_test.yaml therefore sets concurrency: 1, so suites run one at a time as
part of the normal test run, and the mutating suite puts the length unit back when it is done.
The whole suite takes a couple of seconds either way.

melos test passes and melos analyze is clean.

Checklist

• The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
• I have read the Contributor Guide and followed the process outlined for submitting PRs.
• I have updated/added tests for ALL new/updated/fixed functionality.
• I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• [-] I have updated/added relevant examples in examples.

Breaking Change

• Yes, this is a breaking change.
• No, this is not a breaking change.

Everything is additive: the new parameter is optional and defaults to leaving the length unit
alone, and Tolerances is a new class.

Related Issues

Needed by flame-engine/flame#3952, which uses it for worlds that cannot be laid out at a
realistic scale, and reports the underlying problem as a debug-mode warning.

[ufrshubham]

This is a great feature!