feat: external invite + ExternalCommitPolicy component + external_com…

…mitter_permissions (#334)

- Add ExternalInvitePayload + EncryptedGroupInfoBlob messages
  (external_invite.proto). Blob carries plaintext epoch +
  group_state_hash for service-side ordering / fork detection.
- Add EXTERNAL_COMMIT_POLICY component proto
  (external_commit_policy.proto): ExternalCommitPolicyV1 carries
  allow_external_commit + expires_at_ns + expire_in_ns. Toggleable via
  AppDataUpdate(EXTERNAL_COMMIT_POLICY).
- Add external_committer_permissions: ComponentPermissions field to
  ComponentMetadata. Sibling of the existing permissions field;
  governs MLS External Commits per-component. Absent = all-Deny.

Together these provide the two-layer authorization for the QR-invite
flow: EXTERNAL_COMMIT_POLICY is the runtime-toggleable master switch
with time-window controls, and each component declares per-action
capabilities for external committers in its own
ComponentMetadata.external_committer_permissions block.

feat: AppDataUpdateData intent serialization proto (#333)

Local-only serialization shape for libxmtp's group_intents table. Carries
component_id + bytes. Bytes is interpreted by the shape of the component.

Never appears on the MLS wire; collapses the per-component
IntentKind/IntentData proliferation into a single generic shape.

feat: per inbox membership for app data (#332)

feat: add component metadata (#330)

feat: add (super) admin group updates to GroupUpdated (#311)

* feat: add (super) admin group updates to GroupUpdated

* ci: fix test workflow

feat: out-of-band conversation type (#288)

Changes:
1. Defines a 'oneshot' conversation type
2. Defines a 'readd request' oneshot message, which is used to request fork recovery
3. Defines a readd intent, which is the response to the request. The creator of the intent will publish a commit and then send welcomes to the requester.

__________

Optional notes:
Readd requests need to be sent to superadmins outside of the main group (as the sender is forked), however they still need MLS level authentication and privacy guarantees.

We could create a single-use group and then send a message on it, but given only a single message is needed, an alternative is to embed the message on the immutable metadata of the group itself, and have the recipient 'receive' the message at the time of decrypting the welcome, without persisting the group (ie: use openMLS to construct the group/StagedWelcome in-memory, pull the message from the immutable metadata, then throw the group away). That would allow us to avoid:
- Delays from the sender needing to send an additional message on the group after the welcomes have been sent
- Delays from the recipient needing to sync the group after receiving the welcome to receive the message
- Any unintentional consequences around group storage, syncing on it in the future, calling maybe_update_installations, or rendering it in UI. Also means we don't create a new topic on the server.

feat: commit log secret (#284)

feat: remove is-commit - will be determined from payload (#282)

### Remove `is_commit` field from `AuthenticatedData` message in protocol buffer definition as it will be determined from payload
The `is_commit` boolean field (tag 4) is removed from the `AuthenticatedData` message definition in [proto/xmtpv4/envelopes/envelopes.proto](https://github.com/xmtp/proto/pull/282/files#diff-f812a33b13a82e881082c50bb3818e6aad1d114d1141279972acbc496a645fda). A comment is added indicating that tag 4 should not be reused, following the same pattern as the existing comment for tag 1 which was previously used by `target_originator`.

feat: add is-commit to mls validation svc (#279)

feat: remove target originator (#277)