[All] Fix ~45 code scanning warnings in Fable.Transforms

[dbrattli]

Summary

• Address four categories of code scanning analyzer warnings across 15 files in src/Fable.Transforms/
• GRA-STRING-001/002/004: Add explicit StringComparison.Ordinal to StartsWith, EndsWith, and LastIndexOf string overloads
• IONIDE-007: Replace cons-nil list patterns (x :: []) with list literal patterns ([x]), also improving readability of complex multi-element patterns in Rust/Replacements.fs
• IONIDE-005: Replace s = "" conditionals with String.IsNullOrEmpty(s) for more efficient empty string testing
• GRA-TYPE-ANNOTATE-001: Add type annotations to ambiguous string function calls using string<type> syntax

Note: GRA-INTERPOLATED-001 (:s/:d format specifiers) was attempted but reverted — the Standalone tests compile the compiler to JavaScript via Fable, which doesn't handle .NET-style format specifiers correctly.

Test plan

• dotnet build src/Fable.Transforms/Fable.Transforms.fsproj — 0 errors, 0 warnings
• ./build.sh test javascript --skip-fable-library — 2,603/2,607 passed (4 failures are pre-existing locale-dependent Convert format tests)
• CI pipeline passes

🤖 Generated with Claude Code

[github-advanced-security]

Ionide.Analyzers.Cli found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[github-actions]

Python Type Checking Results (Pyright)

Metric	Value
Total errors	18
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_applicative.py	12	Excluded
temp/tests/Python/test_hash_set.py	3	Excluded
temp/tests/Python/test_nested_and_recursive_pattern.py	2	Excluded
temp/tests/Python/fable_modules/thoth_json_python/encode.py	1	Excluded

[dbrattli]

The though with this is to reduce the number of code scanning security warnings for Fable, starting with Fable.Transforms. Currently 726 warnings which doesn't look too good. What do you think? @MangelMaxime @ncave

[MangelMaxime]

I think it is a good idea to reduce the number of warnings.

Especially, because right now even if we have the F# analyzers in place personally I don't look at it because their are too many warnings. 🙈

If we get the number of warning down, or even reach zero we can then only merge a PR when it does not increase it or add new warnings 🙂

[ncave]

@dbrattli But I miss my cons-nil list patterns (x :: []) /jk

Joking aside, it was only done just to avoid the horrible source formatting that list literals have, so the source can stay human readable. But since human readability is no longer important anyway, nobody cares, so it's all good. The less warnings, the better. 👍