Log silent rejection of oversized compressed payloads instead of dropping with no trace

When a compressed packet declares an originalSize larger than FileTransferLimits.maxFramedFileBytes (~1.13 MiB), BinaryProtocol.decodeCore returns nil with no log.

The suspicious-compression-ratio guard (right next to it) already logs a warning. Because of this inconsistency, legitimate large compressed messages sent from Android (which allows up to 10 MiB expanded size) are silently dropped on iOS with nothing visible on either side.

This makes #1618 much harder to diagnose in the field.

Steps to reproduce:

On Android, construct/send a compressed message whose declared expanded size is between ~1.13 MiB and 10 MiB (still within Android’s limit and the shared 50 000:1 ratio guard). Receive it on iOS. Observe: the message never appears and there is no log entry explaining why it was rejected. (Alternatively) Unit test path: the existing oversizedPayloadIsRejected test already proves the packet is refused; before this change there was simply no log. Fix status: I pushed the fix to your fork on branch:

fix/log-oversized-compressed-payload

Commit: adds a SecureLogger.warning that records the declared size and the ceiling. Behavior is unchanged (packet still rejected).