core(kotlin): `absorbR` has no BodySpec path, so sink and warp are stuck at the default throat

[zachshallbetter]

Found while porting warp pairing (#1175). Pre-existing and shared between forces, so it was deliberately not widened there.

The gap

absorbR — the capture radius — is a Body field that no BodySpec parameter can set on Kotlin. JS types it explicitly (packages/core/src/engine/types.ts:303). A Kotlin consumer holding a BodyHandle therefore gets whatever the default is (10px) and has no way to change it.

It affects every force that keys off capture radius:

• sink — the capture radius is the force's whole behaviour.
• warp — the throat size, and it also scales where matter emerges (absorbR · scale + 6).

The engine's own tests work around it by reaching past the public API: FieldHandleTests goes through handle.body.absorbR directly, which is the same shape of workaround that hid the warp gap for as long as it did — a test proving something the public API cannot express.

Suggested fix

Add absorbR to BodySpec, defaulted so no existing call site changes, in the same way #1175 added twistDeg and warpScale. Then update the tests that currently reach through handle.body to go through the spec, so the workaround stops masking the gap.

Worth checking whether Swift has the same hole before fixing, so the three planes move together rather than Kotlin alone.

[zachshallbetter]

Correction: this is a two-plane gap, not Kotlin-only. Retitle accordingly.

Verified on main:

• Kotlin BodySpec (android/.../runtime/FieldHandle.kt:124) has no absorbR, and BodyHandle.set() does not expose it. No path at all.
• Swift BodySpec (swift/Sources/FundamentalCore/Engine/FieldHandle.swift:201) also has no absorbR, and neither BodyParams nor BodyHandle.set carries it. The programmatic path has the identical hole.
• JS types it at types.ts:303.

The planes differ only in the escape hatch. Swift's declarative host can set it (UIKitFieldHost.swift:273, passed at :250) and Swift's Body initialiser takes it. Kotlin has neither — only direct field mutation, as its own scenes do at Scenes.kt:52.

So a consumer holding a BodyHandle is stuck at the default radius on both native planes. That affects every force keyed to capture radius: sink, where the radius is the behaviour, and warp, where it also scales where matter emerges.

Worth fixing on both planes together rather than Kotlin alone, so the parity story does not move sideways.