v0.3.1 — keyboard follows interactive dismissal

iOS fixes for the keyboard and gesture edges, back-ported from the frame's lift into a pure-Swift app where they were found in daily use.

Fixed

• Footer follows an interactive keyboard dismissal. A list with keyboardDismissMode="interactive" drags the keyboard down with the finger, and iOS fires no keyboard notification for that, so the footer stayed lifted in mid-air until the keyboard had fully gone. A 1pt view now rides the keyboardLayoutGuide and re-lays out the sheet on every move (iOS 17+ reads the guide without the safe area; iOS 15/16 treat the safe-area rest position as "no keyboard").
• No jump when the keyboard hides mid-drag. With enableBlurKeyboardOnGesture, the resign fired a keyboard hide that animated the sheet to a detent while the finger was still moving it. While the sheet owns the drag, the hide only updates the lift; the release settles as usual.
• In-gesture hand-off reports a settled layout. When the header reaches the top and the list takes the rest of the gesture, no settle follows, so onChange / onLayoutChange never fired and content kept the previous detent's body size.
• Footer / handle unmount go through the same path as a height change, so an auto detent re-settles and the layout event carries the new geometry.
• Body unmount drops the content-lock observation instead of leaving it pinned to the old list.
• The content-sized height re-lays out even while resting at a fixed detent (dim progress, footer anchor), and the grabber is drawn above the slots so grabberAreaHeight={0} cannot hide it.

Notes

• iOS only; Android is unchanged.
• The "lift unchanged" early return in the keyboard notification handler is gone: the guide tracker updates the lift first, and the handler still owns keyboardBehavior expand / keyboardBlurBehavior restore and the events.

Full Changelog: v0.3.0...v0.3.1