Work around macOS startup crash in irondash_engine_context

[teamleaderleo]

Summary

Works around an immediate native startup crash on macOS caused by a race
condition in irondash_engine_context 0.5.5.

TriOS receives irondash_engine_context transitively through its
drag-and-drop dependencies. The currently published package and upstream
main branch register the macOS engine context asynchronously, allowing
super_native_extensions to request the Flutter view before the context has
been stored.

This PR temporarily overrides the transitive dependency with a tested fork
commit that:

• registers the engine context synchronously;
• includes nil checks in the context getter methods.

Related upstream work

• Bug report:
  [macOS] Crash on startup: objc_loadWeakRetained in getFlutterView due to race condition in irondash_engine_context irondash/irondash#81
• Tested fix commit:
  orestesgaolin/irondash@220bd91
• Current upstream implementation:
  https://github.com/irondash/irondash/blob/main/engine_context/dart/macos/Classes/EngineContextPlugin.m

Reproduction environment

• Apple Silicon, native ARM64
• macOS 26.5.1
• TriOS current main dependencies
• super_drag_and_drop 0.9.1
• super_native_extensions 0.9.1
• irondash_engine_context 0.5.5
• Crash occurs immediately after launch

Failure behavior

Before this change:

• TriOS crashes during startup with EXC_BAD_ACCESS at address 0x8
• The crashing stack passes through
  IrondashEngineContextPlugin.getFlutterView
• The call originates from super_native_extensions while initializing the
  startup drag-and-drop region

The context is inserted into the Irondash registry using
dispatch_async(dispatch_get_main_queue(), ...), while the drag-and-drop
plugin can request the Flutter view synchronously before that queued block has
run.

Change

Adds a dependency_overrides entry for irondash_engine_context pointing to
the tested fork commit:

220bd911fae213282932b964322f9cc4c274f649

No TriOS application code is changed.

Testing

After the change:

• flutter pub get succeeds
• flutter build macos --release --no-tree-shake-icons succeeds
• The built application opens successfully
• Repeated launches succeed
• The dashboard loads
• A saved mod profile loads
• The mod catalog loads
• The startup crash no longer occurs

Follow-up

This is intended as a temporary downstream workaround. The dependency is
pinned to a specific, inspected commit, and the Git override should be replaced
with an official pub.dev release once the fix is merged upstream and published.

Alternative downstream mitigation and regression testing

TriOS currently wraps its main application body in DragDropHandler, which
creates a whole-window DropRegion during the initial widget build.

As an alternative to the Git dependency override, TriOS could explore a
macOS-specific initialization path that defers creation of the DropRegion
until after the first Flutter frame, or until the native engine context is
known to be available. A fixed delay or first-frame callback would still be a
timing-based workaround, so the underlying dependency should ultimately
handle early context access safely.

A useful regression test for the original failure would be a macOS launch
smoke test that:

• builds the macOS application;
• launches the generated .app;
• waits several seconds;
• verifies that the process is still running;
• terminates the application cleanly.

A normal Flutter widget test would probably not reproduce this crash because
the failure occurs during native AppKit/plugin registration rather than purely
inside the Dart widget tree.

TriOS already has Intel and Apple Silicon macOS build jobs, but the current
workflow runs on tag pushes rather than pull requests. A PR-triggered macOS
launch smoke test could catch this class of startup regression before a
release.