Fix plugin registration race condition on ARM systems

[Uhm-why]

Problem:

• On systems with slower GPU initialization (Ubuntu Asahi, ARM with experimental Mesa drivers), plugins attempted to register before the Flutter binary messenger was ready
• This caused critical warnings:
  • "GLib-GObject-CRITICAL: instance has no handler with id 'XXX'"
  • "CRITICAL: assertion 'FL_IS_VIEW(self)' failed"
• These critical errors appeared during app startup

Root Cause:

• fl_view_get_engine() returns valid engine pointer, but the binary messenger inside may not be initialized yet
• Plugins immediately tried to set message handlers on unready messenger
• This triggered assertion failures in Flutter's view system

Solution:

• Check BOTH engine and messenger availability before plugin registration
• Use fl_engine_get_binary_messenger() to verify messenger is ready
• Gracefully skip registration with warning if not ready

Impact:

• Eliminates critical GLib-GObject and FlView assertion errors
• Prevents attempts to access uninitialized messenger
• Makes error handling more robust on ARM systems with experimental drivers
• Improves app stability during initialization

Note:

• This fix addresses the plugin registration timing issue specifically
• Other startup issues may require separate investigation
• Tested on Ubuntu Asahi 24.04 ARM64 (Apple M2, Asahi Mesa driver)

[Uhm-why]

I just signed the CLA. Do I need to re-submit?