scientific(membership): issue downstream observation-to-local-support coordinates #650

Finding

#649 makes the Membership support itself reconstructable and privacy-reduced, but the canonical wire is intentionally sorted and omits downstream observation/document identity. A downstream owner such as #639 therefore cannot bind each of its own observations to the correct projection-local member coordinate without re-sorting raw MemberId values or otherwise reproducing the owner mapping.

That is a DDD leak: Membership should issue the local coordinate mapping at the same time it builds the projection. Analysis should retain its own document/evidence identity and only consume the Membership-issued coordinate.

Required RED

For an input slice containing multiple members, time-varying observations, and duplicates, require the owner-issued projection to expose a coordinate slice parallel to the caller's admitted observation order where each entry contains:

• the projection-local member_ordinal chosen by Membership; and
• the exact canonical EventTime supplied for that observation.

The canonical serialized support wire must remain input-order insensitive. Reordering the caller observations may reorder the returned input-coordinate slice, but must not change the canonical support bytes. Duplicate observations must retain duplicate coordinate entries rather than being deduplicated.

No raw MemberId/GroupId may be exposed by this mapping.

Minimal repair

Extend MembershipObservationSupportProjection with a Membership-owned, non-wire input-coordinate mapping derived from the same local ordinal table used to build tepp.membership_observation_support_projection.v1. Do not make Analysis reconstruct that ordinal table.

This mapping is owner-issued analytical coordination data, not natural-person identity and not a standalone serialization authority. #639 can later zip it with its own document IDs when the #605 contract lands normally on protected main.

Refs #605 #638 #639 #649.