[Runtime] Fix wrong file offsets on shared file access on .NET 6 and later

[hpetriffer]

Fixes #2081

The problem

XsWin32FileStream never overrides Position. Since the .NET 6 FileStream rewrite that makes FTell(), FEof(), FReadLine() and the whole RDD record positioning path (SafeReadAt() / SafeWriteAt() / SafeSetPos()) read and write at the wrong file offset, silently and without an exception, for every file opened with shared access.

The class does all of its I/O with the Win32 API on the OS file pointer, but Position falls through to the base class. Until .NET 5 that was fine: FileStream re-verified its cached position against the OS handle on every access once SafeFileHandle had been exposed (VerifyOSHandlePosition). The .NET 6 strategy rewrite removed that, so FileStream.Position is now a purely in-memory counter that the overrides never touch — it stays at 0 while the real file pointer moves.

Runtime	Result
.NET Framework 4.8	OK
.NET Core 3.1 / .NET 5	OK
.NET 6 / 8 / 10	broken

Not a .NET 10 regression — it starts with .NET 6.

Reproduction

VAR h := FOpen(cFile, FO_READWRITE + FO_SHARED)   // -> XsWin32FileStream
FSeek3(h, 6, FS_SET)
? FTell(h)              // expected 6                      .NET 6+: 0
? FReadStr(h, 5)        // expected "World"                 ok
? FTell(h)              // expected 11                      .NET 6+: 0
FSeek3(h, 0, FS_SET)
? FReadLine(h, 100)     // expected "Hello World line1"     ok
? FReadLine(h, 100)     // expected "second line here"      .NET 6+: ""
? FEof(h)               // expected TRUE at end             .NET 6+: FALSE

The serious part is the RDD layer, which positions with oStream:Position := pos and then calls Read() / Write(). With a broken setter those land at the wrong offset with no exception:

.NET Framework 4.8                      .NET 10.0.11
OK   SafeReadAt(6,5) = "World"          FAIL SafeReadAt(6,5) = "Hello"
OK   SafeSetPos(0)+SafeRead = "Hello"   FAIL SafeSetPos(0)+SafeRead = " Worl"

The change

From .NET 6 on, FileStream reads and writes at an explicit offset and does not cache the length of a file that others may write to, so it is correct for shared access by itself. The shared stream therefore becomes a plain unbuffered FileStream that commits on Flush(), selected with the standard define:

#ifdef NET6_0_OR_GREATER   -> managed implementation
#else                      -> the existing Win32 implementation, unchanged
#endif

Below .NET 6 nothing changes. The #else branch is byte-for-byte the shipped class, CreateFileStream() keeps its original body including the platform check and the buffered non-Windows fallback, and XsFileStream is untouched. Verified by diff and by reflection over the built assemblies:

build	P/Invokes	declared members
net46	9	Flush, get_Length, Lock, Read, Seek, SetLength, Unlock, Write, WriteByte
net8.0	0	Flush, Lock, Unlock

Lock() / Unlock() are overridden on the managed shared stream to set NetErr(TRUE), because SetErrorState() only sets NetErr for a sharing violation (32) while a lock violation is 33 — the Win32 implementation does that itself. Deliberately on the shared stream only: putting it on XsFileStream also changed exclusive streams, which then reported NetErr on .NET 6+ but not on .NET Framework.

Reviewer notes

Two differences remain between the two paths. Both are pre-existing defects of the Win32 implementation, fixed only on the .NET 6+ side because the pre-.NET 6 path is intentionally left untouched:

• Read() with a non-zero offset copies count bytes instead of the number actually read, zeroing the caller's buffer past the end of the file.
• SetLength() seeks to the new length unconditionally instead of clamping only when the position is past the new end.

Every SetLength / SafeSetLength caller in the RDDs was checked; none depends on either behaviour.

The first two commits are intermediate steps (a Win32-based fix, then the fully managed one) and are superseded by the third — squash if preferred.

Testing

A purpose-built harness (~65 assertions: FTell/FEof/FReadLine, the RDD positioning path, EOF and partial reads, all Seek origins, truncate, lock error state, SafeFileHandle drift) run against the real XSharp.Core:

	net48	net8.0	net10
harness	0 failures	0 failures	0 failures

XSharp.Core.Tests File IO 3/3 and XSharp.RDD.Tests 29/29 across repeated runs. Both target frameworks build with 0 warnings.

Lock error state verified identical on both targets — shared: FError=33, NetErr=True; exclusive: FError=33, NetErr=False.

Performance on net472 (BenchmarkDotNet, RDD record pattern) was measured before deciding to gate the change: the Win32 implementation is roughly 25 % faster there than the managed one, mostly because FileStream.Position does a SeekCore syscall on .NET Framework. That is why the old path is kept below .NET 6 rather than replaced everywhere.