Adapt Java CSE machine

[mattcce]

Description

This change adapts the Java CSEC machine to source-academy/java-slang#79.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Code quality improvements

How to test

These changes are extremely minimal and exist only to adapt the frontend to a modified backend system. This is tested manually.

1. Pull CSEC: Precompiled classes java-slang#79.
2. Locally link the above (yarn link in java-slang, then yarn link "java-slang" in frontend).
3. Start the frontend.
4. Run the Java CSEC machine.

As it is not the responsibility of the frontend to test changes to the backend, there is no need to test the functionality introduced by source-academy/java-slang#79.

Checklist

• I have tested this code

[sentry]

Bug: The raw stderr function, which expects two arguments, is passed to runJavaCseMachine. The CSE machine will likely call it with one, causing incorrect error handling.
_{Severity: MEDIUM}

Suggested Fix

Wrap the stderr callback when passing it to runJavaCseMachine to hardcode the error type, ensuring it conforms to the expected single-argument signature. For example: stderr: (msg: string) => stderr('Runtime', msg).

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/commons/utils/JavaHelper.ts#L103

Potential issue: The `stderr` function defined in `JavaHelper.ts` requires two
arguments: `type` and `msg`. When passing this function as a callback to
`runJavaCseMachine`, it is not wrapped. External systems like the CSE machine are
expected to provide a single string argument to their I/O callbacks. This mismatch will
result in the `type` parameter receiving the error message and the `msg` parameter being
`undefined`, leading to incorrect error classification and potential runtime errors
within the `stderr` function body. A similar callback for the JVM path is correctly
wrapped, establishing a pattern that was not followed here.

_{Did we get this right? 👍 / 👎 to inform future reviews.}