Script decoding falls back to platform default charset, breaking reproducibility

**Describe the bug**

Script file reading falls back to the platform default charset when no script encoding is configured, which makes build results dependent on the host encoding.

`ScriptRunner.executeRun` decodes the script with `new String(bytes)` when `encoding` is `null` (ScriptRunner.java:202-206), i.e. the platform default charset. The `ScriptRunner` javadoc for `setScriptEncoding` (ScriptRunner.java:119-127) documents this default, but on JDK versions before 18 the platform default is locale/OS-dependent, so:

- the same project can build successfully on one machine and fail (or behave differently) on another when the script contains non-ASCII characters; and
- on JDK 18+ the default silently changes to UTF-8, so behavior differs across JDK versions.

Additionally, `MirrorStreamWrapper.write(byte[], int, int)` decodes mirrored output with `new String(b, off, len)` (FileLogger.java:155), always the platform default charset, which can disagree with the charset used to read the script.

**To Reproduce**

Run a hook script containing a non-ASCII literal (e.g. `println "café"`) with `setScriptEncoding` never called, on two machines with different default charsets (or on JDK 11 vs JDK 17+).

**Expected behavior**

A stable, predictable default (e.g. UTF-8) regardless of platform, with an option to override.

**Actual behavior**

The decoded script content (and mirrored output) depends on the host's platform default charset.

**Suggested fix**

- Default `encoding` to `StandardCharsets.UTF_8` when not explicitly set instead of using the platform default.
- Decode mirrored bytes in `MirrorStreamWrapper` with the same explicit charset.