perf(python): back int64 arrays with typed storage

[dbrattli]

TypedArrayCompatible in the Python Replacements.fs excluded Int64/UInt64
with a comment inherited from the JavaScript target:

// Don't use typed array for int64 until we remove our int64 polyfill
// and use JS BigInt to represent int64

That constraint has never applied to Python. The Rust core has backed these with
NativeArray::Int64(Vec<i64>) / UInt64(Vec<u64>) all along, and
Int64ArrayCons / UInt64ArrayCons are exported from array_.py — nothing had
ever emitted them.

The visible effect: Array.map over an int64[] emitted map(f, xs, None) and
fell back to boxed Generic storage, keeping one wrapper object per element.
Only array literals and Seq.toArray specialized, because those go through the
typed constructor rather than a library call — which is also why it looked fine
in passing.

Effect

For int64 this is a win on both axes rather than a tradeoff, because int64
values are still pyo3 wrappers, so the boxing that specialization avoids is
real. 1000 elements, release core:

storage	a == b	sum(a)	a[500]
Int64	0.09 µs	17.6 µs	22.5 ns
Generic	8.53 µs	33.6 µs	20.0 ns

Equality is 95× because Vec<i64> == Vec<i64> compares entirely in Rust, where
Generic walks element-by-element through Python. Memory drops from an 8-byte
pointer plus a wrapper object per element to a flat 8 bytes.

Storage kind before → after, via quicktest:

                    before     after
literal             Int64      Int64
Seq.toArray         Int64      Int64
Array.init          Generic    Int64
Array.zeroCreate    Generic    Int64
Array.map           Generic    Int64
Array.filter        Generic    Int64
Array.append        Generic    Int64
Array.rev           Generic    Int64
Array.sort          Generic    Int64
uint64 Array.map    Generic    UInt64

Note on scope

Typed storage extracts to i64/u64 and raises if the value does not fit,
where Generic accepts anything. For a statically-typed int64[] that is
unreachable, and the boundary values are covered by the new tests — but it is a
tightening, not a pure no-op, so it is worth knowing about.

This does not close the remaining specialization holes: List.toArray,
Array.ofSeq and Set.toArray still produce Generic, because those library
functions erase 'T before they allocate and there is no cons for the call site
to pass. Fixing that means threading a parameter through F# sources shared with
other targets, so it is deliberately left out of here.

Test plan

• Python target suite with --force-fable-library: 2445 passed (was 2442)
• New TestArray.fs coverage — the file had no int64 tests at all, which
  is why this went unnoticed. Asserted against .NET first (228 array tests
  pass on .NET): value round-tripping through the storage, boundary values
  (Int64.MinValue/MaxValue, UInt64.MaxValue) that would expose a botched
  extraction, and structural equality — the operation the specialization is for
• Quicktest verification of the storage kinds above, with values intact
  including Int64.MaxValue round-tripping as 9223372036854775807

🤖 Generated with Claude Code

[github-actions]

Python Type Checking Results (Pyright)

Metric	Value
Total errors	34
Files with errors	4
Excluded files	4
New errors	✅ No

Excluded files with errors (4 files)

These files have known type errors and are excluded from CI. Remove from pyrightconfig.ci.json as errors are fixed.

File	Errors	Status
temp/tests/Python/test_hash_set.py	18	Excluded
temp/tests/Python/test_applicative.py	12	Excluded
temp/tests/Python/test_nested_and_recursive_pattern.py	2	Excluded
temp/tests/Python/fable_modules/thoth_json_python/encode.py	2	Excluded