fragment reassembly cap of 256 fragments rejects files that bitchat-ios sends and accepts

Summary

Since #666, FragmentManager rejects any fragment stream with total > MAX_FRAGMENTS_PER_ID (256), and FragmentingPacketSender refuses to create one. At MAX_FRAGMENT_SIZE (469 bytes) that is about 117 KiB per file. bitchat-ios accepts up to 10,000 fragments per stream and a 1 MiB payload (BLEFragmentAssemblyBuffer, FileTransferLimits.maxPayloadBytes), so the two platforms no longer agree on what a file transfer can be.

Effect

• A file over ~117 KiB sent from bitchat-ios is dropped by bitchat-android at the first fragment, with only a Log.w. The sender shows it as sent.
• bitchat-android cannot send anything over ~117 KiB either, although AppConstants.Media.MAX_FILE_SIZE_BYTES advertises 10 MiB and the picker accepts files up to that size. The send fails after selection.
• Voice notes are near the line: at the 20 kbps recorder setting, ~45 s of audio is 117 KiB.

Where

• AppConstants.Fragmentation.MAX_FRAGMENTS_PER_ID = 256
• FragmentManager.handleFragment: if (fragmentPayload.total > maxFragments) return null
• FragmentingPacketSender: passes MAX_FRAGMENTS_PER_ID to createFragments

Suggestion

The memory concern that motivated #666 is already covered by MAX_FRAGMENT_TOTAL_BYTES (1 MiB per stream) and MAX_GLOBAL_FRAGMENT_TOTAL_BYTES (4 MiB overall). The per-stream count could match bitchat-ios at 10,000, which keeps the byte caps as the real bound and restores parity with what iOS sends. If a lower count is intended, MAX_FILE_SIZE_BYTES and the picker should reflect the size that can actually be delivered, and the rejection should surface to the user rather than a log line.