Carried-object attachment: object 'held by' an agent then detaches, with possession-over-time GT

[bamdadd]

Rationale

A general building block underneath hand-off and many activity scenarios is a single object that is attached to (carried by) an agent — its world point moves rigidly with the holder — and then detaches (set down / released) at a defined frame. The benchmark needs this as a first-class, reusable primitive with ground-truth possession over time, so downstream consumers can score "is this object currently held, and by whom".

This is the single-agent special case of the two-agent hand-off (#63); building it first keeps that scenario simple.

What to build

A helper that binds an object entity to a holder entity's carry point over a frame range, drives the object's center from the holder's motion while attached, and records a possession timeline (held-by id, then None after detach).

Acceptance criteria

• A helper attaches an object entity to a holder over [start, end) frames so the object's world point follows the holder (optionally with a fixed carry offset), then detaches at end.
• Ground truth records possession over time: object id -> holder id while attached, None after detach; the detach frame is explicit.
• Additive only. Possession GT rides in a sidecar (per the order.py precedent); the byte-golden analytic manifest is unchanged and the new GT is opt-in.
• Geometry check: while attached, the object's per-frame position equals holder-point + offset to floating-point tolerance; after detach it no longer tracks the holder.
• Round-trips to JSON and reloads.
• A test verifies attach -> follow -> detach and the possession timeline.

Files / data model to extend

• src/multicam_sim/entities.py — Entity / EntityFrame (the object is an entity with a center point that this helper drives).
• src/multicam_sim/order.py — sidecar precedent for the possession GT.
• src/multicam_sim/scene.py — Scene container.

Open design note

Attachment can be modelled as a build-time helper that bakes the object's frames, or as a declarative binding resolved at manifest time. Either is fine provided the golden manifest stays byte-identical; the choice is left to the maintainer.