add_members (by inbox_id) does not enforce MAX_GROUP_SIZE, unlike add_members_by_identity

[teyrebaz33]

Discovered while investigating the ignored test tracker (#3233): test_max_limit_add (crates/xmtp_mls/src/groups/tests/mod.rs) has been #[ignore]d, and running it against a live backend confirms it's a real bug, not just a flaky/slow test.

Root cause

Group::add_members_by_identity (crates/xmtp_mls/src/groups/mod.rs) checks member_count + inbox_id_map.len() > MAX_GROUP_SIZE before queuing a membership update intent, returning GroupError::UserLimitExceeded if the group is already at the 250-member cap.

Group::add_members -- the inbox_id-based counterpart, used e.g. when adding an already-registered member by inbox ID directly -- has no equivalent check. A group already at 250 members can still be grown past the limit through this entry point.

Reproduction

1. Create a group with 1 member (the creator).
2. Add 249 more members via add_members_by_identity (group is now at 250, the cap).
3. Call amal_group.add_members(&[bola.inbox_id()]).

Expected: returns Err (group is at capacity).
Actual: succeeds, group ends up at 251 members.

Confirmed directly against a live backend (just backend up + cargo test ... -- --ignored --nocapture) -- logs show the 251st installation being added to group membership and the commit publishing successfully.

Impact

MAX_GROUP_SIZE is meant to be a hard protocol-level cap (see crates/xmtp_configuration/src/common/mls.rs). This entry point silently bypasses it, so a group's membership can grow unbounded via add_members.

PR incoming with a fix mirroring the existing add_members_by_identity guard, plus un-ignoring test_max_limit_add.