fix: avoid tableFromJSON codegen for Cloudflare Workers compatibility

[ensky]

Problem

The daily-rollup scheduled handler (extractAsArrow in
packages/server/workers/lib/arrow.ts) cannot succeed on Cloudflare
Workers as currently written.

apache-arrow's tableFromJSON() internally walks records and
triggers vectorFromArray → makeBuilder → new StructBuilder →
new Builder → createIsValidFunction, which calls
new Function(...) to generate validity-check code at runtime. The
Cloudflare Workers runtime forbids this:

EvalError: Code generation from strings disallowed for this context
    at new Function (<anonymous>)
    at createIsValidFunction
    at new Builder
    at new StructBuilder
    at makeBuilder
    at vectorFromArray
    at tableFromJSON
    at extractAsArrow

I observed this on a real counterscale deployment with CF Workers
compatibility_date = "2025-08-08". The cron has thrown on every fire
since the worker was deployed; no Arrow file has ever been written to
the daily-rollups R2 bucket.

Fix

Replace tableFromJSON(records) with a small recordsToTable helper
that pivots records to columnar form and builds Utf8 / Float64
Arrow Data directly via makeData, then assembles them into a
RecordBatch. This bypasses the Builder/codegen path entirely.

Column types are inferred per column from the first non-null sample
(number → Float64, otherwise → Utf8). This preserves the same column
shape tableFromJSON was producing for this consumer — the records
written here only ever have string and number fields.

Public API of extractAsArrow is unchanged (same return shape, same
filename pattern, same R2 write).

Tests

Adds workers/lib/__tests__/arrow.test.ts:

• Round-trips a mixed string/number record set through
  tableToIPC / tableFromIPC and asserts values match.
• Handles null / undefined values.
• Returns an empty Table for empty input.
• Proxies globalThis.Function and asserts no new Function(...)
  call happens during table construction or IPC serialization — a
  unit-level guarantee that the Workers runtime restriction is
  satisfied.

Notes

Happy to adjust style/structure to match the project's conventions.
The change is small and self-contained to workers/lib/arrow.ts plus
the new unit test.

[stordahl]

Hey @ensky, thanks for the contribution and fixing this bug! Apologies for the radio silience - I'm picking back up work on counterscale as a volunteer while Ben focuses on Modem. I left a few comments, but overall this looks great

[stordahl]

nullCount is always 0, but null/undefined inputs produce empty strings via the ?? new Uint8Array(0) fallback. A downstream reader will see "" for rows that were originally null, which loses the null signal. Either construct a validity bitmap and set nullCount correctly, or add a JSDoc on recordsToTable documenting that it does not preserve Arrow null semantics.

[ensky]

Implemented a validity bitmap for Utf8 data. It marks non-null rows valid, reports the actual null count, and keeps null/undefined values as Arrow nulls after IPC round-trip. The existing no-codegen guard still passes.

[stordahl]

Same issue as buildUtf8Data — nullCount is 0 but null/undefined values are written as 0.0 via values[i] ?? 0. This silently converts nulls to zeros.

[ensky]

Applied the same shared validity bitmap to Float64 data, so null/undefined values no longer decode as 0.0. Placeholder payload values remain internal to the Arrow buffer.

[stordahl]

This test only verifies row count, not value round-trip fidelity. It should explicitly assert that rows 2 and 3 ({ a: null, b: null } and { a: undefined, b: undefined }) decode with null values for column b.

[ensky]

Expanded the regression coverage to assert decoded values for both Utf8 and Float64 null/undefined rows. It also verifies that all-valid columns retain an empty validity bitmap.