Non-ASCII cat stdout fails accounting when stderr is redirected

Reading a non-ASCII file with cat while also reporting a missing operand fails with an internal accounting error if stderr is redirected away. The valid file's stdout is lost and exit code 1 becomes 126.

Reproduced on just-bash@3.6.0 and current main (9ab0e0d34c1d24978cd40ae890a91ccb223cc606).

import { Bash } from "just-bash";

const bash = new Bash({ files: { "/present.txt": "שלום\n" } });
const result = await bash.exec("cat /present.txt /missing.txt 2>/dev/null");
console.log(result.stdout, result.stderr, result.exitCode);

Expected:

{ stdout: "שלום\n", stderr: "", exitCode: 1 }

Actual:

{ stdout: "", stderr: "bash: redirection: invalid stdout accounting\n", exitCode: 126 }

2>/errors.txt fails the same way. ASCII file contents do not trigger this reproduction.

cat returns byte-shaped stdout. applyRedirections preserves that encoding but computes the final stdout accounting credit with utf8ByteLength, re-encoding the byte string. When the original stderr contributes to the prior accounting total, the inherited stdout credit can exceed the actual byte length. accountResult then rejects it.

The focused fix is to use the existing stdoutIsBytes decision when measuring final stdout, as the output accounting owner already does. A broader stream-routing change is unnecessary.