Function read_post_commit_component_bytes 

pub fn read_post_commit_component_bytes(
    id: ComponentId,
    mls_group: &MlsGroup,
    staged_commit: &StagedCommit,
    registry: &ComponentRegistry,
) -> Result<Option<Vec<u8>>, ComponentSourceError>

Compute the post-commit value of a single component by overlaying the staged commit’s AppDataUpdate proposals on top of the pre-commit dict. Last-write-wins matches the lazy-batching apply order in xmtp_mls’s accumulate_app_data_updates: every Update(payload) is decoded against the running value (so collection deltas compose), and Remove collapses to None.

Returns Ok(None) when the component is absent both before and after the commit, or when it was explicitly removed. Returns Err only when an Update payload fails to decode against the running value — the same condition validate_app_data_update_proposals_in_commit would also reject upstream, so callers can treat decode failure here as “validator will surface the real error” and short-circuit.

Used by the commit validator to evaluate per-component invariants (notably MIN_SUPPORTED_PROTOCOL_VERSION) that need the post-commit view from the AppData dictionary.

Registry semantics

registry is the pre-commit COMPONENT_REGISTRY (i.e. the state of the dictionary entry before the staged commit applies). Callers should load it once via xmtp_mls’s load_component_registry on the live mls_group and reuse it across all validator helpers — same registry feeds validate_app_data_update_proposals_in_commit and any other per-component checks.

Implication for commits that modify COMPONENT_REGISTRY in the same commit as a write to a newly-registered component: such a write fails with UnknownComponent here because the new entry is not yet visible in the pre-commit registry. This matches what the receiver-side validator (validate_app_data_update_proposals_in_commit) enforces today and is the documented convention across the commit path: registry mutations and writes that depend on those mutations MUST land in separate commits.