Expose custom create-room initial state and exact state reconciliation through matrix-sdk-ffi

[bananawalnut]

Problem

A retry-safe encrypted room-creation flow needs both of these capabilities through generated Swift matrix-sdk-ffi bindings:

1. Atomically include m.room.encryption and a custom idempotency marker state event in the original create-room initial_state request.
2. After an ambiguous response, sync/query room state and classify zero, exactly one, or multiple exact marker matches before deciding whether any retry is safe.

Observed against an artifact based on matrix-rust-sdk f50309786e5d4019d7d73f4b126483f68068f785. Its generated Swift create-room parameters expose standard room metadata, invitees, preset/visibility, and an encryption convenience flag, but the downstream preflight did not establish a supported custom initial-state event surface or an authoritative exact-marker query path.

Creating the marker after room creation is not equivalent: a timeout can occur after server creation but before the post-create marker, leaving no safe reconciliation key. Blind retry can create duplicate private rooms.

Requested FFI surface

Expose supported Swift bindings for custom initial state, for example:

CreateRoomParameters.initial_state: [InitialStateEvent]

Each event should carry an event type, state key, and JSON content without requiring a second authenticated transport.

Also expose a supported room-state query capable of retrieving an exact state event by (event_type, state_key) after sync, or an equivalent API that lets callers enumerate authoritative room state without timeline heuristics.

Requirements

1. A custom marker and m.room.encryption can be submitted in the same create-room request.
2. JSON content is passed without leaking it into logs or error strings.
3. Query results preserve enough state-event identity to distinguish zero, one, and multiple candidate rooms.
4. The API does not synthesize local authority when the server result is ambiguous.
5. The design supports cancellation and retry without duplicate room creation.
6. Standard invite handling and encryption convenience options remain compatible with custom initial state.

Why this matters

This enables durable operation markers, exact-match reconciliation after timeout, and fail-closed duplicate prevention for private encrypted-room onboarding.