bug: ios caret is drawn in the wrong place when content is added above a focused field inside an ion-toolbar in ion-footer

### Prerequisites
- [x] I have read the Contributing Guidelines.
- [x] I agree to follow the Code of Conduct.
- [x] I have searched for existing issues that already report this problem.

### Ionic Framework Version
v9.x (@ionic/core 9.0.2, also reproduced on 9.0.1)

### Current Behavior
On iOS, when a focused text field lives inside an `ion-toolbar` in a bottom
`ion-footer`, and an element is inserted ABOVE that field inside the same
toolbar, the text caret keeps its previous screen position instead of following
the field.

The field itself does not move (the footer is bottom-anchored, so it grows
upwards). The caret ends up drawn one inserted-element-height too high — visually
inside the newly added element, which is not editable at all.

The caret only corrects itself when the user types a real character. Programmatic
attempts to force a re-measure all have no effect: `setSelectionRange()` with the
same range, `setSelectionRange()` to a different range and back, `setRangeText('')`,
`document.execCommand('insertText', '')`, `blur()` + `focus()`, and toggling
`inputMode` off and back.

### Expected Behavior
The caret should stay with the field it belongs to, as it does on every other
layout change.

### Steps to Reproduce
1. Open the reproduction on an iOS device or the iOS Simulator (Safari or a
WKWebView).
2. Tap the text field in the footer so it has focus and shows a blinking caret.
3. Wait 2.5s — a 60px block is revealed above the field, inside the same
`ion-toolbar`.
4. The field stays put, but the caret is now drawn inside the gold block above it.
5. Type one character: the caret jumps back to the correct place.

### Code Reproduction URL
Self-contained single file, no build step, loads Ionic from the CDN:
https://gist.github.com/tzdevelopteam/2d444e8822c8dedbe43a4faa72df564a

(save the file and open it on an iOS device — it needs no build step)

```html

const field = document.getElementById('field');
field.addEventListener('focus', () => {
setTimeout(() => (document.getElementById('above').style.display = 'block'), 2500);
}, { once: true });

```

### Isolation already done
- **`ion-toolbar` is required.** Putting the same markup directly in `ion-footer`
(no toolbar) makes the caret behave correctly. That is the smallest difference
between working and broken.
- `ion-content` is NOT required — it reproduces with the footer alone.
- Not `ion-textarea`: a plain light-DOM `` reproduces it, as above.
- Not the iOS input shims: `initialize({ inputShims: false })` changes nothing.
- Not the toolbar's `contain: content`: overriding it with `contain: none` changes
nothing.
- Not application CSS: reproduces with `ionic.bundle.css` and nothing else.
- Hand-rolling the same geometry without Ionic components (an absolutely
positioned flex-column page with a growing flex-item footer) does NOT reproduce
it, so this appears specific to the toolbar's own structure.

### Ionic Framework
Ionic Framework (@ionic/core)

### Installed Packages
@ionic/core 9.0.2 (CDN), reproduced in an Angular app on @ionic/angular 9.0.1.

### Additional Information
Reproduced on iOS 26.5 (iPhone 17 Simulator) in Safari, and on a physical iPhone
inside a Capacitor WKWebView. Not observed on Android/Chromium.

Impact is cosmetic — the caret is only mis-drawn, typed text still goes to the
right place, and the first keystroke fixes it. But in a chat composer (tap
"reply", a reply preview opens above the input) users see the caret sitting in
the preview for as long as they hesitate before typing.

Start by locating the ion-toolbar implementation and reproduce the gist on iOS Safari and in a WKWebView. Compare the toolbar case with the direct ion-footer case, then verify that revealing content above a focused field keeps the caret aligned without requiring a keystroke.

Written by the indexing model from the issue text.