Function expand_app_data_update_to_changes 

pub fn expand_app_data_update_to_changes(
    component_id: ComponentId,
    operation: &AppDataUpdateOperation,
    old_value: Option<&[u8]>,
    registry: &ComponentRegistry,
) -> Result<Vec<ExpandedComponentChange>, ComponentSourceError>

Expand an AppDataUpdate proposal payload into the per-element changes that should be checked against the component registry.

• Bytes components: returns a single Update change with the new payload bytes.
• Collection components (ADMIN_LIST / SUPER_ADMIN_LIST): parses the payload as a TlsSetDelta<InboxId> and emits one entry per mutation, with op = Insert for Insert, op = Delete for Remove / RemoveByHash.
• AppDataUpdateOperation::Remove (any component): a single Delete entry with no value.

old_value is the component’s pre-commit stored bytes (from the AppData dictionary). It’s only consulted for RemoveByHash resolution on collection components: given the prior TlsSet<InboxId>, we build a hash → InboxId index and resolve each RemoveByHash back to the concrete key being removed so the validator sees the inbox id the peer is targeting. If the hash doesn’t match any prior key (or old_value is None), the expansion surfaces value: None and the subsequent CRDT apply step surfaces the real error.

Used on the receiver side to feed validate_component_write for each distinct change inside a single AppDataUpdate proposal.

The steady-state validator dispatches through lookup_component directly so it can also call Component::validate_invariant without a second binary search. This wrapper is retained for callers that don’t need the invariant hook.