[Bug]: BaseSandboxFilesystem.edit fails when replaceAll=false because the generated Python command contains literal \\n sequences`

Describe the bug**

`BaseSandboxFilesystem.edit(..., replaceAll=false)` fails before reading or modifying the target file. The generated `python3 -c` program contains literal `\\n` character sequences instead of actual newline characters. On a POSIX shell, `\\n` inside a double-quoted argument is passed to Python unchanged, so Python raises a `SyntaxError`.

This affects the default single-replacement path used by the `edit_file` tool. The file is left unchanged.

The bug is present in AgentScope-Java 2.0.0 and is still present on `main` at commit `9b77823678b4ae919f7c14bc10fb7560879979d7` (`2.0.1-SNAPSHOT`).

**To Reproduce**

1. Use a sandbox-backed filesystem whose `execute` implementation runs commands through a POSIX shell and provides `python3`.
2. Create a file such as `/tmp/example.txt` containing `old`.
3. Invoke the filesystem edit operation with `replaceAll=false`, for example through the tool:

```text
edit_file({"path":"/tmp/example.txt","old_string":"old","new_string":"new"})
```

4. Observe that the operation fails with a Python syntax error and `/tmp/example.txt` is unchanged.

The generated command starts with:

```text
python3 -c "import sys, os, base64, json\npayload = ..."
```

A minimal shell-level reproduction is:

```sh
python3 -c "import sys, os, base64, json\npayload = {}"
```

**Expected behavior**

The first occurrence of `old_string` should be replaced with `new_string`, and the edit operation should return a successful `EditResult`.

**Error messages**

```text
Error editing file '/tmp/example.txt': unexpected server response: File "", line 1
import sys, os, base64, json\npayload = json.loads(...)
^
SyntaxError: unexpected character after line continuation character
```

**Environment (please complete the following information):**

- AgentScope-Java Version: 2.0.0; also reproducible from `main` at `9b77823678b4ae919f7c14bc10fb7560879979d7` (`2.0.1-SNAPSHOT`)
- Java Version: OpenJDK 21.0.12
- OS: macOS 26.3.2 arm64 host; POSIX sandbox shell with Python 3

**Additional context**

The command is constructed in:

```text
agentscope-harness/src/main/java/io/agentscope/harness/agent/filesystem/sandbox/BaseSandboxFilesystem.java
```

The Python source lines are currently joined using Java string fragments ending in `\\n`, for example:

```java
"python3 -c \"import sys, os, base64, json\\n"
```

This produces a backslash followed by `n` at runtime, not a line feed. POSIX shells do not translate `\\n` inside double quotes. Python then interprets the backslash as a line-continuation character and rejects the following `n`.

The returned process exit code is also not checked before parsing stdout. Because the syntax-error output contains neither the expected `"error"` nor `"count"` JSON field, it is reported as `unexpected server response`, which hides the actual command-execution failure.

Possible fixes:

1. Use actual newline characters (`\n` in the Java source) when building the Python program, or pass the Python program through a quoted heredoc and pass the Base64 payload as an argument.
2. Check a non-zero execution exit code before parsing the expected JSON response.
3. Add a real-shell integration test for `edit(..., replaceAll=false)` that verifies the file contents.