Whole-file reads return empty data for readable zero-size procfs files #219

File.getContent and File.getBytes return empty data for readable Linux procfs files whose reported size is zero. File.read(...).readAll() correctly reads the same file.

Regression coverage first: test/regression/FileProcContents, in the existing Main.hx/build.hxml/stdout.txt layout. Read /proc/self/cmdline through a FileInput, verify it is nonempty, then compare both whole-file helpers with that result. This process's command line remains stable across the reads and does not require any particular machine configuration.

Confirmed on Linux x86_64 with Haxe 4.3.3:

stream has content: true
getContent matches stream: false
getBytes matches stream: false

In src/hx/libs/std/File.cpp, file_contents_string and file_contents_bytes seek to the end to determine the allocation size, then read exactly that many bytes. A length of zero is treated as an empty file. This assumption is not valid for procfs files, which generate data on read. The same design rejects nonseekable inputs and throws when a size estimate exceeds the content available, although those cases are source observations rather than the procfs reproduction above.

Preserve an efficient path for ordinary regular files, but use an EOF-based bounded-chunk read when the size is unavailable or not authoritative. Treat a size estimate as a reservation hint rather than proof that no data exists. Enforce maximum representable output sizes while growing, preserve actual read errors, and keep GC and descriptor cleanup correct if allocation fails.

Add coverage for a nonseekable input and a size-overreporting pseudo-file where fixtures are available. Linux-only fixtures should be skipped explicitly on other platforms. No runtime implementation changes are included.