Fix getGlobalCurrentTaskMeta null handling

[wondenge]

Description

_getGlobalCurrentTaskMeta treats a cleared task slot (null) as a valid meta object. _clearCurrentTask sets CURRENT_TASK_META[componentIdx] = null, but the getter only checks for undefined, so null passes through and {...null} returns {} truthy, but with no taskID. This causes _lowerImportBackwardsCompat to skip its auto-task-creation fallback and throw invalid/missing async task meta.

This shows up when an import fires between two export calls. Export trampolines for types that need allocation (strings, lists, etc.) call realloc via _utf8AllocateAndEncode before creating their task. If the component has imports wired into internal functions (allocator internals like dlmalloc::memalign), those imports go through _lowerImportBackwardsCompat in a window where CURRENT_TASK_META is null from the previous export's cleanup but no new task exists yet.

Error: invalid/missing async task meta
    at _lowerImportBackwardsCompat (component.js)
    at component.wasm._ZN8dlmalloc8dlmalloc17Dlmalloc$LT$A$GT$8memalign17h4d574c3a3414c418E

The fix adds a null check alongside the existing undefined check in the intrinsic codegen. A codegen test is added to initialization.js that transpiles the non-wizered-init component and verifies the generated _getGlobalCurrentTaskMeta includes the null check. This is a string match on generated code rather than a behavioral test, a proper integration test would need a component with imports wired into allocator internals to actually trigger the crash, which is hard to set up generically. The codegen assertion is a pragmatic alternative that catches accidental removal of the null check. I'll file a follow-up issue for a behavioral test that exercises the actual failure path.

[vados-cosmonic]

Thanks for the contribution @wondenge -- I'd like to get the behavioral test in here before this merges -- the generated-code-only check doesn't really do much to help IMO, and regardless it would be better to check in the regression test with the fix.

[wondenge]

Thanks for the contribution @wondenge -- I'd like to get the behavioral test in here before this merges -- the generated-code-only check doesn't really do much to help IMO, and regardless it would be better to check in the regression test with the fix.

Hey @vados-cosmonic sorry for the delay, been swamped this week. Thanks for cleaning things up in the meantime. I'd still like to add a behavioral test to this PR before it merges if that works for you - a test component in crates/test-components that hits the actual failure path rather than the string match. That way the fix and its regression test go in together.

[vados-cosmonic]

Hey @wondenge I really appreciate it, please take your time!

BTW, Jco 1.17.7 is on it's way out the door (this link should work soon) -- so feel free to give that a try as well. The first implementations of future<t> coming out of a function are now in place (being able to send in a future<t> will be in soon as well).