Make the sponsored guard test locale-independent

[KazenDev]

The sponsored rooted filesystem test asserts on the message mkdir prints, and coreutils translates that message. So it passes on the English CI runners and fails on any machine with a non-English locale. Here the suite is 615 pass / 1 fail, and this is the one failure:

Expected pattern: /mkdir:.*late.*File exists|helper exited with code 74/
Received message: "mkdir: no se puede crear el directorio «late»: El archivo ya existe"

Repro: bun run --cwd sdk test fails with LANG=es_CO.UTF-8 and passes with LC_ALL=C. Nothing about the guard is broken — the write is still refused, and escaped.ts is still never created. Only the wording the test listens for is wrong.

Root cause

The test's directBroker() spawns the helper with env: request.env, and getSystemProcessEnv() (sdk/src/env.ts) returns process.env, so the test machine's locale reaches mkdir. mkdir writes its localized message to stderr, and runHelper throws that stderr verbatim:

throw new Error(
  stderrBuffer.toString().trim() ||
    `Sponsored filesystem helper exited with code ${exitCode}.`,
)

Fix

Pin the locale on the helper subprocess, in the test's own broker:

env: { ...request.env, LC_ALL: 'C' },

The assertion itself is left exactly as written. LC_ALL=C alone is enough — it takes precedence over LANG and LANGUAGE.

Why pin the locale instead of loosening the assertion

Loosening the pattern to /mkdir:.*late|helper exited with code 74/ also makes it pass anywhere, but it costs precision: it stops checking the reason, and late then matches the prefix of a longer name such as late-ish or latex. Pinning the locale keeps the original assertion, reason text included, and leaves nothing cryptic behind.

It is also the established fix for this exact problem:

• GNU coreutils hit the same bug in 2006 — a test expecting an English message while the program answered in German — and fixed it by setting LC_ALL=C in the test suite.
• Bitcoin accepted the same fix in their #28286: "the test failed because it checks for English error message... So I explicitly set env variable 'LC_ALL' to 'C' in the code of failing test."
• reproducible-builds.org: "For build systems, it's thus best to use LC_ALL directly."

Who this helps

Anyone running the SDK suite outside an English locale. This is currently the only red test in the suite, and it is red for a reason that has nothing to do with the code under test — so a contributor on a Spanish, German or Chinese machine either sets the locale by hand or learns to ignore a real-looking failure. After this, local matches CI.

Verification

Public CI builds the SDK and smoke-tests the binary, but it does not run this suite, so this was reproduced locally:

• LANG=es_CO.UTF-8 bun run --cwd sdk test — 616 pass, 0 fail
• Removing the LC_ALL pin brings the original failure back with the Spanish message, so the pin is what fixes it
• bun run --cwd sdk typecheck — clean
• prettier --check on the file — clean

Follow-up, not in this PR

runHelper already has a stable, locale-proof message of its own (Sponsored filesystem helper exited with code N), but it prefers the localized stderr whenever there is any, so the structured signal only surfaces when mkdir says nothing. Preferring the structured message there — or forcing a locale for sponsored helpers generally — would fix the class of problem rather than this instance. The second one changes the environment every sponsored command runs in, not just this test, so it is raised here rather than changed unilaterally.

[codebuff-team]

This is a clean, well-reasoned fix. The root cause is correctly identified: mkdir's stderr message is locale-translated, and the test in sdk/src/__tests__/sponsored-rooted-filesystem.test.ts asserts on that raw string, so it fails whenever LANG/LC_ALL isn't English on the machine running the suite. Pinning LC_ALL: 'C' on the spawned helper's env (rather than loosening the regex) is the right call — it preserves the specificity of the assertion instead of just matching a substring that could false-positive on names like latex.

The change is minimal, scoped to a single test file, and doesn't touch product code or forbidden paths. The comment added alongside the fix is a bit verbose for a one-line change but does explain the reasoning for future readers, which is fine.

One minor note: it might be worth checking if other tests in the same suite or sibling suites spawn subprocesses the same way and could hit the same issue — but that's a nice-to-have, not a blocker for this PR. The verification steps (reproducing with LANG=es_CO.UTF-8, confirming failure without the pin, confirming pass with it) are exactly what a reviewer would want to see. Straightforward to port.