Ports FlutterKeyboardInsetManager from Objective-C to Swift. This is intended to be as close to a 1:1 translation of the original as possible: I've tried to preserve the structure, control flow, and behaviour of the original, and tried to use only a few Swift conveniences such as guard and optional binding. We can make this Swiftier in followups.

We continue to expose the class to Objective-C++ via @objc. The keyboard mode enum and the manager's delegate protocol, which were previously declared in FlutterViewController_Internal.h and FlutterKeyboardInsetManager.h are now part of the Swift implementation, and having an _Internal.h header for an already-internal class was less than idiomatic, regardless.

FlutterViewController now holds the manager through a new FlutterKeyboardInsetManagerProtocol rather than the concrete type, mirroring how the other migrated managers are wired up, which lets us substitute a fake and gives us an eventual path off of OCMock. I've added a uiTaskRunner accessor to the delegate protocol and implemented on FlutterViewController so the manager can reach the UI task runner directly rather than through engine, which keeps the vsync setup testable.

There are a few details were kept deliberately as close as possible to the original, since they are easy to get subtly wrong when moving to Swift:

• setUpKeyboardSpringAnimationIfNeeded is always invoked at the end of the keyboard animation block, including with a nil animation, so that the absence of a position animation clears the cached spring animation instead of leaving a stale one behind. hideKeyboardImmediately clears it as well.

• isKeyboardNotificationForDifferentView compares the delegate against the engine's view controller by object identity (=== / !==), matching the original pointer comparison rather than -isEqual:.

• The vsync callback is delivered with a plain dispatch to the main queue, as before, and the delegate is not retained for the duration of the animation.

The tests in FlutterViewControllerTest.mm needed a more than a mechanical update. Swift classes don't co-operate with OCMock the way the original Objective-C class did:

OCMock can't intercept a call one Swift method makes to another (they aren't dynamically dispatched like they are in Obj-C), and the generated header marks the class objc_subclassing_restricted, so it can't be subclassed from the test target to form a partial mock. I've reworked the affected tests to drive the real keyboard inset manager and assert on observable results (the computed inset, whether a vsync client was created, whether a pre-seeded spring animation was cleared) rather than verifying that one internal method called another; this seems like an improvement regardless. Normally I would have pushed to a followup, but as noted, Swift dispatch is more efficient than Obj-C but it means we can't intercept these calls in OCMock anymore, regardless.

I've kept a minimal FakeFlutterKeyboardInsetManager conforming to the protocol for a test that confirms the view controller drives the manager on viewDidDisappear.

This also adjusts the exported symbols check to allow symbols for Swift classes exported in the DATA section from InternalFlutterSwift (and also InternalFlutterSwiftCommon). The _TtC is standard Swift ABI name mangling:

• _Tt indicates a Swift type exported to Obj-C.
• C indicates a class.

Issue: #112232

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.