Seems that this is a platform problem. This baffles me. It just can not
be, that this can not be avoided in native app. I'm sure we have some
specific setup that causes this kind of bug.

Basically what happens is as follows (Pixel 3a, API 35, 1080px x 2160px):

1. Framework does measure pass. Toolbar is measured w/o taking status
   bar inset into consideration and receives `measuredHeight` of
   `140px`.

2. `Screen` receives initial dimensions of `1838px` (dunno where the rest
   of height is lost).

3. Framework dispatches window insets -> `CustomToolbar` applies
   `paddingTop = 60px`.

4. `CustomToolbar` layout where it receives `height=140px` from
   parent.

5. Another `CustomToolbar` layout where it receives `height=140px` from
   parent.

6. Yet another `CustomToolbar` layout, but it receives `height=200px`
   this time.

7. `Screen` layout with appropriate dimensions of `height=1778px`.

What is jarring is that these intermediate states are visible leading to
"flicker". I've tried to stabilize it by overriding `Toolbar.onMeasure`
and increasing `measuredHeight` by `statusBarInset` until the inset is
considered in `onLayout` for the first time & it **partially** fixed the
problem - the header view was stable, however the text inside (screen
title) still flickered. Would have to "stabilize" it manually & I really
don't want to do that. This must be solvable in some reasonable way.