[Feature] Richer 2D contact event payloads

[vmarcella]

Overview

Expand CollisionEvent payloads so gameplay systems can make better decisions
for audio, decals, damage, and effects without reaching into backend-specific
data structures.

Current State

CollisionEvent currently exposes one representative contact point, one
normal, and one penetration value on Started. That is sufficient for basic
gameplay reactions, but not for richer collision-driven systems.

Scope

Goals:

• Add optional multiple-contact data or a summarized contact collection
• Add relative velocity at contact
• Add impulse or force-like data if the backend can provide it reliably
• Keep the event payload backend-agnostic

Non-Goals:

• Exposing raw Rapier manifolds
• Full solver debugging tools
• 3D contact payload design

Proposed API

pub struct ContactPoint2D {
  pub point: [f32; 2],
  pub normal: [f32; 2],
  pub penetration: f32,
}

pub struct CollisionEvent {
  pub kind: CollisionEventKind,
  pub body_a: RigidBody2D,
  pub body_b: RigidBody2D,
  pub contacts: Vec<ContactPoint2D>,
  pub relative_velocity: Option<[f32; 2]>,
  pub normal_impulse: Option<f32>,
}

Acceptance Criteria

• Additional payload fields are defined and documented
• The backend maps contact data without exposing vendor types
• Missing backend data is represented explicitly and consistently
• Tests cover single-contact and multi-contact cases
• Docs explain the cost tradeoff of richer payload collection
• Demo or sample code shows at least one practical use

Affected Crates

lambda-rs, lambda-rs-platform

Notes

• A richer payload may justify a separate "extended events" API if it's better for the default
  event path to remain simple.
• Impulse data may only be meaningful after solver execution.