Fixes #175074

There was an implicit expectation in the resizing code: When the virtual keyboard is up on mobile, the view's physicalSize remains fixed, and any resizes (presumably caused by the virtual keyboard itself) should be considered as viewInsets.

This expectation was broken inadvertently by my PR: #172493

The sequence of events that lead to the reported issue:

1. View's physical size is calculated based on window size.
2. Text editing starts, virtual keyboard comes up.
3. View's physical size remains unchanged, and the difference caused by the keyboard is reported as view insets to the framework.
4. (so far so good).
5. When resizeToAvoidBottomInset is true, the framework will re-render its content to fit the available size.
6. The new render call comes with a new size that's basically physical height - bottom inset.
7. The engine takes that new size and applies it to the DOM.
8. (now the view's DOM element has been resized incorrectly).
9. ...
10. Eventually, this leads to the new insets being calculated incorrectly resulting in negative insets which cause the framework to throw.

The fix involves the following:

1. Respect the expectation mentioned above: when the keyboard is up, view's physical size should remain unchanged.
2. If we ever end up with negative insets, catch it earlier in the engine so it's easier to debug the root cause.
3. New regression test.