bug(ios): no keyboard set during embedded engine init

> > So this was use-before-init? Just making sure that the root cause of the warning can't be addressed. No problem eliminating the warning but unnecessary calls are ... unnecessary!
>
> I believe so, but I'm not 100% sure. I could try to investigate more thoroughly in the future, if we'd prefer that.
>
> Thinking a little bit more on it... I wonder if the iOS engine is just setting OSK height "later" than the Android app does. If it were set 100% in advance, we wouldn't get the warning then, I believe. Then again... our Android dev is on break at the moment, thus he's probably not running the latest alpha - which could be the only reason we're not seeing the error from Android too.

So, a little more info is now available to us thanks to #9217:

```js
{
configReport: {
embeddingApp: AppleMobile,
hostDevice: {
browser: native,
formFactor: phone,
OS: ios,
touchable: True
},
initialized: False,
keymanEngine: app/webview
},
keyboard: {
id: '',
langId: '',
version: ''
},
model: {
id: ''
},
osk: {
banner: blank,
layer: default
}
}
```

Therefore, we may assume that this is occurring when there's no loaded keyboard yet. This smells to me like an old warning from previous versions that we eventually silenced:

https://github.com/keymanapp/keyman/blob/3148aa7b8c8a4b5de574d49bdf6edc80dcb6761a/web/source/kmwdom.ts#L1495-L1497

(12.0 permalink, but it was finally removed in 15.0 stable / 16.0 alpha by #6890.)

The logic 'gatekeeping' the warning _is_ a bit different, but the underlying state that's triggering it seems to match pretty well.

_Originally posted by @jahorton in https://github.com/keymanapp/keyman/issues/9206#issuecomment-1627917615_

------

Additional info:

At the time of the original PR, simply loading up the Keyman app, changing the keyboard once, and rotating the mobile device from portrait to landscape, then back - just once - was enough to reliably trigger the error. It may not have even needed _that_ much.

There is a slight flash (flash-of-unstyled-content style) of an improperly-laid-out keyboard during the init that's visible. It's only about a frame, and it seemed to happen just once, but it's as if the keyboard was loading before the size information was properly registered.

This may also provide some hints toward the long-running keyboard-load flash-of-unstyled-content we see in the Android app.