feat: hardening sdk on participant_context

[wolf4ood]

Problem

Flow operations on an existing flow (terminate, started, completed, suspend, resume, status, and the notify_* callbacks) received the caller's participant context as _ctx and ignored it. Flows were loaded with WHERE id = $1, so a participant authenticated for its own context could read or change another participant's flow just by knowing its flow id. That includes overwriting the flow's data address via started/resume. Flow ids were also globally unique, so start/prepare with another tenant's id returned 409, revealing that the id exists.

Changes

• DataFlowRepo: fetch_by_id and delete now take participant_context_id, and update keys on (flow.participant_context_id, flow.id). A flow owned by another context is reported as not found.
• Postgres:
  • All queries filter on participant_context_id.
  • A new migration changes the data_flows primary key to (participant_context_id, id), so flow ids are unique per participant context.
• Memory store: keyed by (participant context, flow id).
• DataPlaneSdkInternal: every flow operation and send_callback passes the caller's context through. The public fetch_by_id gains a ctx parameter.
• Callback URL: now built with Url::path_segments_mut, so the caller-supplied flow id is always a single percent-encoded segment. New SdkError::InvalidCallbackUrl.

Breaking changes

• DataFlowRepo and DataPlaneSdkInternal::fetch_by_id signatures changed. Custom repo implementations need updating.
• Schema migration: primary key change on data_flows.

Tests

• Store test suite (runs for memory and Postgres):
  • Another participant context cannot fetch, update or delete a flow.
  • Two participant contexts can each own a flow with the same id.
• SDK tests: every flow operation returns NotFound for another context's flow, and the handler is never called.
• Callback URL tests: encoding of the flow id, and rejection of an invalid base URL.