[Bug]:MySQL AgentStateStore rejects Harness sandbox session IDs containing

[CyberXavier]

### Environment

- AgentScope Java: `2.0.1-sn-v2-SNAPSHOT`
- Java: 17
- Store: `MysqlAgentStateStore`
- Harness sandbox enabled

### Problem

When Harness persists sandbox state with session isolation, `SessionSandboxStateStore` generates a session ID like:

```text
sandbox/session/conv-a12d03e7-e213-4905-ad82-ad199ae1ea70

MysqlAgentStateStore then rejects it in validateSessionId(...):

java.lang.IllegalArgumentException:
AgentStateStore ID cannot contain path separators

Relevant call chain:

SandboxManager.persistState(...)
 -> SessionSandboxStateStore.save(...)
 -> slotSessionId(...)
 -> MysqlAgentStateStore.save(...)
 -> validateSessionId(...)

Expected behavior

Harness sandbox state should be persistable through MysqlAgentStateStore, or the sandbox store should encode/sanitize its internal scoped session IDs before delegating to AgentStateStore.

Question

Should SessionSandboxStateStore use a storage-safe encoding for IDs such as sandbox/session/<sessionId>, or should MysqlAgentStateStore allow / in session IDs?

The database itself can store /; the failure comes from the application-level validation.

[zouyx]

#2022 have fixed this issue, would you like to confirm?

[tsujishiki]

2.0.2依旧有这个问题

[haosong384]

The MySQL half of this issue was already fixed on main by 769eac1, which removed the path-separator check from MysqlAgentStateStore.validateSessionId().

PostgresAgentStateStore.validateSessionId() still enforces it, so the same failure reproduces verbatim when PostgresAgentStateStore is used instead:

java.lang.IllegalArgumentException: AgentStateStore ID cannot contain path separators
    at PostgresAgentStateStore.validateSessionId(PostgresAgentStateStore.java:721)
    at PostgresAgentStateStore.save(PostgresAgentStateStore.java:265)

Grepping the repository confirms Postgres is now the only AgentStateStore implementation still enforcing this check, so the implementations are inconsistent.

I have opened #2733 to apply the same fix to Postgres, following the rationale from 769eac1: the constraint is filesystem-oriented and meaningless for a relational store, where the value is bound as a PreparedStatement parameter and never used as a filesystem path.

On the open question in the issue description ("should SessionSandboxStateStore encode, or should the store allow /?"): #2336 proposes the encoding approach on the Harness side. The two are not mutually exclusive — even if #2336 lands, Postgres would still diverge from MysqlAgentStateStore and JsonFileAgentStateStore (the latter accepts such ids and Base64-URL encodes them internally). Happy to close #2733 if maintainers prefer to converge on the Harness-side fix alone.