Module js_safe 

JS-boundary safe-integer walkers (productionization 09.8, design 226 Stage A): the opt-in strict_i64 check that refuses an out-of-Number.MAX_SAFE_INTEGER Int crossing to JS with a typed error instead of silently rounding it. JS-boundary safe-integer enforcement (productionization 09.8; design 226 Stage A).

An OwnedValue::Int crosses every JS boundary as an f64 number today (the single-number model, R10). Above Number.MAX_SAFE_INTEGER (2^53 − 1) that conversion collides adjacent values — fatal for PK identity (two distinct ids become equal in JS). These walkers find the first offending Int in each shape that crosses, so a boundary with strict_i64 enabled refuses the frame with a typed error instead of silently rounding. Mandatory since design 226 Stage C (§8) — int64 columns exist, and every JS boundary (wasm, napi, the daemon’s bare-cell HTTP read wire) runs the walk unconditionally; Stage E adds the bigint lane and makes it column-aware.

Note the bound is deliberately stricter than the round-trip guards (the CDC capture guard and the scan-path check_number_bounds): 2^54 round-trips i64 → f64 → i64 exactly, yet is NOT a safe JS integer — its f64 neighbors are more than 1 apart, so distinct nearby i64s would collide. Float cells are never checked: they are f64 already, whatever their magnitude.

Only the shape walkers live here — the ones that need the engine’s own change, flat and view types. The cell-level bound they all bottom out in lives in rindle_value::js_safe and is re-exported below.

Functions

unsafe_int_in_cells

The first out-of-safe-range Int in a positional cell slice, if any.

unsafe_int_in_flat_changes

The first out-of-safe-range Int anywhere in a flat-change batch — path parent rows, op rows, and every nested WireNode.