fix: support Date as a typed-array element and island-crossing type

[techfreaque]

Problem

Date was supported as a standalone static type but could not appear as an array element (Date[]) or cross the island boundary in jsvalIn. Two gaps:

1. isSupportedArrayElem didn't include "date", so Date[] was rejected at the type-mapping layer.
2. elemKindC threw InternalCompilerError for date elements, and elemAccess returned "ref" (wrong — Date is stored as f64).
3. jsvalLiftable and jsvalIn didn't allow Date values to cross the island boundary (alongside bytes and url).

Fix

ir/nodes.ts — isSupportedArrayElem: add case "date". Dates are epoch-ms f64 scalars at the C level, stored in SCR_ELEM_F64 slots.

emit-types.ts:

• elemKindC: add case "date" returning "SCR_ELEM_F64" (same storage as f64).
• elemAccess: return "f64" for date elements.

emit-exprs.ts:

• streamTypedRefAdapter: handle date alongside f64 (same scr_arr_get_f64 path).
• jsMarshal: add case "date" emitting scr_jsval_from_f64 — passes the epoch-ms timestamp as a JS number to the island.

lowerer.ts:

• jsvalLiftable: add t.kind === "date" alongside bytes and url.
• jsvalIn: add e.type.kind === "date" alongside bytes and url.

Verification

Date[] compiles and round-trips correctly. Date values marshal into the island as f64 millisecond timestamps. packages/compiler builds clean.

[vercel]

@techfreaque is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Additional Suggestions:

1. Promise.all producing Date[] selects the pointer-ref store adapter instead of the f64 adapter, causing an f64 epoch-ms payload to be stored through a ref store into an f64 array slot (type mismatch / miscompile).

2. streamFromArrayAdapter reads Date[] elements via scr_arr_get_ref (pointer read) instead of scr_arr_get_f64, miscompiling ReadableStream.from(dateArray).

3. LLVM backend's emitJsMarshal lacks a case "date", so a Date crossing the island falls into the JSON-composite default and hits jsonWriteHelper, which throws LlvmUnsupportedError for date.

[vercel]

Additional Suggestion:

On the LLVM backend, Date[] arrays use the wrong element accessor family and elemKindNum throws LlvmUnsupportedError for date, so Date-as-array-element (this PR's headline feature) miscompiles on native and hard-fails (SC3001) on wasm32-wasi.

[techfreaque]

Fixed all four issues in d0d05ae:

1. Promise.all store adapter: emit-exprs.ts — store selector now uses scr_promise_all_store_f64 when elem.kind === "date".
2. streamFromArrayAdapter read path: emit-exprs.ts — reads via scr_arr_get_f64 for date elements, same as f64.
3. LLVM emitJsMarshal: llvm/emitter.ts — added case "date": before case "f64": so island-crossing dates use scr_jsval_from_f64.
4. LLVM elemKindNum + elemAccess: llvm/shapes.ts — added case "date": return 0 (SCR_ELEM_F64) in elemKindNum and updated elemAccess to treat date as f64 — fixes wasm32-wasi SC3001 and native array construction.