feat(runtime): allow Python interactors in interact

[TakalaWang]

Summary

interact refuses any interactor written in Python, even though Python interactors run in the same Wasm sandbox, under the same limits, as Python contestants, which interact already accepts. This PR removes that one refusal so Python interactors work. No sandbox or resource limit changes.

Background: what the guard actually checks

forge has two kinds of build artifact:

Kind	What it is	Example
wasm	one compiled Wasm module	C, C++, Rust, Go
runtime-bundle	an interpreter Wasm module plus the source files it runs	Python (CPython Wasm + main.py)

Both kinds execute inside the same Wasm runtime, under the same policy:

• instruction budget and memory limit;
• no network, no process or thread creation;
• a virtual filesystem holding only the files the host passes in.

A runtime bundle is not less isolated than a standalone module. It is still Wasm; it just carries its interpreter with it.

ServerRunner.interact and the browser runner's interactArtifacts both start with:

if (interactorArtifact.kind !== "wasm") {
  throw new Error("Interactive judge artifacts must be standalone Wasm modules.");
}

So the check is about the artifact's packaging, not about safety. The property interaction really needs is that a program can read fd 0 as a stream while the other side is still writing. That is already checked per runtime driver, for both sides, in prepareArtifactInteraction (src/runner/artifact.ts):

if (driver.interactive !== "streaming") {
  throw new Error(`Runtime driver '${driver.id}' does not support streaming interactive execution.`);
}

The CPython driver is streaming, which is why a Python contestant already works in interact. The kind guard only blocks the same driver on the interactor side. Bundles whose driver cannot stream fd 0 are still rejected by the driver check.

Why it matters

DOMjudge-style interactors are commonly written in Python. In NOJV, which uses @wasm-oj/server to run problem interactors on the server for in-browser Test, all four interactive problems use Python interactors. With the guard in place, Test is unavailable on every one of them; with it removed, they run end to end.

Change

• Remove the kind guard in ServerRunner.interact (src/server/server-runner.ts) and in the browser runner Worker's interactArtifacts (src/runtime/runner.worker.ts). The driver check above stays the only gate.
• docs/library-contract.md: either side may be a standalone Wasm module or a runtime bundle; bundles that cannot stream fd 0 are still rejected.
• CHANGELOG.md: Unreleased entry.

Verification

• New server integration test, "runs a CPython interactor against a compiled contestant" (src/server/judge.integration.test.ts):
  • The CPython interactor reads the secret from its input file, writes a challenge and checks the C contestant's reply.
  • It expects both sides to exit 0 and the transcript 42\n / 41\n.
  • With the guard restored, it fails with "Interactive judge artifacts must be standalone Wasm modules."
• WASM_OJ_RUN_JUDGE_INTEGRATION=1 pnpm exec vitest run src/server/judge.integration.test.ts: 3/3 pass.
• pnpm run ci:verify passes: 194 files, 956 tests, plus build.
• Downstream, through createServerEngine: a CPython guess-the-number interactor against a C++ binary-search contestant returns interactor exit 42 with the full transcript, in about 3 s.

Not changed

Resource policies, metering, the trusted-judge path, and the streaming capability check are untouched. A Python interactor gets exactly the limits a Python contestant gets.

🤖 Generated with Claude Code

[TakalaWang]

For context: NOJV (a downstream user) will run checkers and interactors in the browser for its Test button. It needs this PR (its four interactive problems use Python interactors), #95 and #99 (which fixes browser interact, #98) in one release. With #99 merged too, a CPython interactor and a C++ contestant give AC in Chromium, Firefox and WebKit. This PR and #99 merge cleanly apart from the CHANGELOG.