Resolve handling of window height on web backend

### Describe the bug

If you create an application on desktop, the size of the app window is fixed both horizontally and vertically. This means that a COLUMN box with flex=1 will fill the available space; elements floated to the bottom of that box will appear at the bottom of the window. If the content is larger than the window in the vertical dimension, a layout warning is raised.

However, a web page doesn't have this vertical constraint - a web page can have effectively "infinite" height, because the page can scroll by default. There is no natural "bottom" of the page, or natural height to which the web page should expand.

### Steps to reproduce

Run the scroll container demo. The content *in* the scroll container is much bigger than the actual browser window; but what should the vertical scrolling behavior be?

### Expected behavior

In the scroll container example: there are multiple possible interpretations:

* The *page* could scroll, giving effectively infinite height to the window.
* The window content could be constrained to the height of the browser window, and the *scroll container* made to scroll.

More generally, there are two cases of interest:
1. The natural height of the window content is less than the size of the browser window
2. The natural height of the window content is greater than the size of the browser window

I can see three possible interpretations:
1. The window is laid out with an allocation height of 0, but no error is raised for overflowing that allocation. This will result in the minimum possible height for the app content; the vertical layout will be as tight as it can be (i.e., vertical flex widgets will assume their minimum height).
2. The window is laid out with an allocation height matching the window, with errors raised for overflow. This is the closest analog of the desktop case; if content *could* expand larger than the app window, the user would be expected to add a scroll container.
3. The window is laid out with an allocation height matching the window, with *no* errors raised for overflow. This is the most "browser like" interpretation; but it makes browsers distinct from other platforms.

### Screenshots

_No response_

### Environment

- Operating System: All
- Python version: All
- Software versions:
- Toga: 0.5.0

### Logs

```

```

### Additional context

To my reading, (2) would be the interpretation that is most consistent with other platforms.

(3) could be an interesting feature addition; if apps on *all* platforms were to automatically add scrolling if the main content extended beyond the height of the main window, that would make the default behavior on *mobile* a little more intuitive; but the behaviour on desktop would be a little alien.

Start by running the scroll container demo described in the issue and observe both the page and container behavior. Since no source file or test is named, trace the web backend's window-height and layout handling from that demo. Done requires a decided behavior for both smaller and larger natural content, implemented consistently and covered by validation.

Written by the indexing model from the issue text.