File close discards buffered write errors and lets saveContent report success #215

A buffered write can succeed while the actual device write fails during close. libhxcpp ignores fclose's return value, so FileOutput.close and File.saveContent can report success after losing the data.

Regression coverage first: test/regression/FileCloseWriteError, using Main.hx/build.hxml/stdout.txt. On Linux, write a short string to /dev/full, then close without an explicit flush. Also test File.saveContent directly and use an explicit flush as a control. Other platforms need an equivalent failing-output fixture.

Confirmed on Linux x86_64 with Haxe 4.3.3 against checkout 03a4e8d, with the unrelated process reaper work present:

close reported write failure: false
flush reported write failure: true
saveContent reported write failure: false

Expected: all three operations report the write failure. /dev/full is a deterministic ENOSPC fixture, so the test does not need to fill a real disk.

In src/hx/libs/std/File.cpp, fio::destroy calls fclose(io) and ignores its result. _hx_std_file_close delegates to destroy(true). The Haxe cpp File.saveContent/saveBytes/copy helpers write and then close without a separate flush, so this reaches normal file-saving APIs.

Explicit close should report a failed final flush or close while still invalidating the FILE pointer. fclose has already consumed the stream even on failure, so cleanup must not retry using the old FILE pointer. Preserve the filename and error information before clearing the object. GC finalization needs a separate nonthrowing cleanup policy.

Related to #113, but distinct: that report addresses a crash when fwrite itself detects failure. This one concerns deferred failure at fclose and silent success. The local regression reproduces it without any runtime implementation changes.