[Python/Beam] Align random* error messages with .NET and fix pyright errors

[dbrattli]

Review follow-ups for fable-compiler#4488, scoped to Python and Beam.
JS/TypeScript is intentionally out of scope — see "Follow-ups for fable-library-ts" below.

Python

• Delete dead fable-library-py/fable_library/Array.fs. This file is not in Fable.Library.Python.fsproj and declares module ArrayModule, so the new randomShuffle/randomChoice/randomSample members added to it in [All] Add missing Array, List, and Seq random choice/shuffle/sample members and tests fable-compiler/Fable#4488 were never compiled. Removing the file prevents future confusion.
• Fix error messages in the Rust extension (src/array.rs). All new random operations were raising bare PyException with argument-name-only messages ("source", "count", "randomizer"). Replaced with descriptive PyValueError messages aligned with dotnet/fsharp FSharp.Core resource strings. Randomizer validation now matches .NET's dynamic format exactly: "The index is outside the legal range.\nrandomizer returned <value>, should be in range [0.0, 1.0)."
• Fix pyright type stubs (core/array.pyi). The new Callable[[], float] signatures caused 13 type errors in test_array.py because Fable transpiles F# (fun () -> 0.0) as returning Float64, not float. Changed to Callable[[], SupportsFloat]. PyO3's extract::<f64> still accepts Float64 via __float__.

Beam

• Align randomizer error message with .NET. Same dynamic format as the Python fix, via io_lib:format.
• Use andalso in guard for random_sample_by (idiomatic Erlang).
• Tail-recursive random_choices_by. Replaced lists:map(fun(_) -> ... end, lists:seq(1, Count)) (which allocated an intermediate driver list and used O(n) lists:nth per pick) with a choices_loop/5 helper that converts the input to a tuple once for O(1) indexed access — matching the pattern already used by shuffle_loop and sample_loop in the same file.

Verification

• cargo check on fable-library-core: clean
• ./build.sh test python: 2233 passed, 0 failed
• uv run pyright --project pyrightconfig.ci.json temp/tests/Python/: 0 errors (was 13)
• ./build.sh test beam: 2390 passed, 0 failed

Follow-ups for fable-library-ts (not in this PR)

Verifying against dotnet/fsharp src/FSharp.Core/local.fs and FSCore.resx surfaced two places where fable-library-ts/Array.fs diverges from actual .NET and should be revisited in a separate PR:

1. Randomizer out-of-range validation

.NET uses executeRandomizer in Microsoft.FSharp.Primitives.Basics.Random:

invalidArgOutOfRangeFmt argName
    "{0}\n{1} returned {2}, should be in range [0.0, 1.0)."
    [|SR.GetString SR.outOfRange; argName; value|]

• Exception type: ArgumentOutOfRangeException (not ArgumentException).
• Resource string key: outOfRange = "The index is outside the legal range." (not Arg_ArgumentOutOfRangeException = "Specified argument was out of the range of valid values.").
• Second line includes the actual returned value.

fable-library-ts currently uses the static string SR.Arg_ArgumentOutOfRangeException with no value interpolation, and raises ArgumentException rather than ArgumentOutOfRangeException. The Python and Beam implementations in this PR match the .NET format with dynamic value; fable-library-ts should follow suit.

2. Array.randomChoiceBy empty-source check

.NET uses LanguagePrimitives.ErrorStrings.InputArrayEmptyString = "The input array was empty." (resource key arrayWasEmpty) — specifically for Array.randomChoiceBy only. List.* and Seq.* still use inputSequenceEmpty. fable-library-ts currently uses inputSequenceEmpty for all three.

Python cannot fix this inside the Rust extension alone because a single random_choice_by function services all three collection paths there (List.randomChoiceBy delegates to Array.randomChoiceBy via F#). Fixing this properly requires either per-collection entry points in the Rust extension or a parameterized message argument. The same design decision applies to Beam. Recommend solving in fable-library-ts first, then propagating.

3. Double-to-string formatting

.NET's default double-to-string produces "1" for 1.0, while Rust's {} gives "1" and Erlang's ~w gives "1.0". The dynamic randomizer message is therefore close but not byte-identical to .NET across all three targets. Likely not worth fixing unless users are parsing messages.

---

🤖 Generated with Claude Code

[ncave]

Thank you @dbrattli !