I'm sure it probably doesnt change the effect, but still worth noting that max frame size MUST be 512 bytes or higher.
I don't think the problem you saw necessarily points to an issue with the fix Gordon sugested, but instead to an issue with the engine in general...
The problem presumably happens at 1MB because the session defaults to a 1MB 'incoming bytes capacity'. If a local max-frame-size is set, this capacity is used to calculate the incoming window size as the number of max-sized frames that could be accepted at the time without breaching the 'capacity'. If a local max-frame-size is not specified (default), then a fixed window size of 2^31-1 is 'calculated' each time.
Proton-j and by the looks of it proton-c both recalculate their session incoming window whenever they are issuing a flow, which amongst other cases they will look to do during a process of the transport if the session incoming window hits 0. The issue is presumably that if the incoming window hits 0 (because a local max-frame-size was set, and the resulting window has now been used) and the session has also received its capacity of incoming bytes at the same time, then the re-cacluated window will still be 0, something that happens if you send messages over <session-capacity> in size.
In short, if the local max-frame-size is being set, then the incoming session window behaviour seems basically broken for messages over <session-capacity>. If so, this likely hasnt been noticed for the most part because few are setting max-frame-size.
EDIT: fixed remote -> local for frame size usage.