[WASM] GL ES call to `GetProgramInfoLog` may throw unexpectedly

# Summary
Retrieving the program info log on the `browser-wasm` platform may crash with `ArgumentOutOfRangeException` as a result of a `string.Substring` operation with mismatching length argument.

# Steps to reproduce
- Platform: browser-wasm
- Framework: tested on DotNet 10.0
- API: WebGL 2.0 + GL ES 3.0
- Tested library version: Silk.Net.OpenGLES 2.23.0
- IDE: tested with Visual Studio 2026 Community Edition (Insiders [11918.235])

I've prepared [a repository that sets up a minimal crash repro](https://github.com/paralaxsd/SilkCrashRepro). To trigger the crash, please clone the repository and perform the following steps:

- Please ensure that WebAssembly build tools are installed as is described in the repo's `Readme.md` file.
- Open the solution and press F5 to enter Debug mode.
- Observe: the [call to `gl.GetProgramInfoLog(program)` in `SilkProgramInfoLogRepro.TryStringOverload`](https://github.com/paralaxsd/SilkCrashRepro/blob/77f10ba3618b71f4228906f5f744ddbebebbd74b/Burnside.Packages.Vibe.WasmPlayer/SilkProgramInfoLogRepro.cs#L89) throws rather than returning the info log detailing the program linker fault.
- The span overload of `GetProgramInfoLog?` is not affected which can be shown by commenting the call to `TryStringOverload` and stepping through the subsequent function call in `TrySpanOverload` instead.

# Comments
The symptom for this fault could be easily fixed by changing the implementation in `Silk.NET.OpenGLES.GL.GetShaderInfoLog(uint shader, out string info)` from

```csharp
info = info.Substring(0, (int) length);
```

to something like

```csharp
info = info.Substring(0, Math.Min((int)length, info.Length));
```

At this time I can only speculate why the length argument is returned to us with a value exceeding the info log's length. At some point it seemed as if a trailing '\n' character was trimmed from the end of the info log (the debugger stated that the string was changed) but I can't show this conclusively.

The GL type repeats this pattern of calling `string.Substring` with a given length a few more times. I do wonder if these could also be affected.

Start by reproducing the failure with the linked SilkCrashRepro and then inspect Silk.NET.OpenGLES.GL.GetShaderInfoLog and the related string-overload implementations. Check each reported Substring length against the returned string, and consider the issue resolved when GetProgramInfoLog returns the linker log without throwing and the repeated patterns have been assessed.

Written by the indexing model from the issue text.