[Bug]:LocalFilesystemSpec falls back to user.dir as project root, leaking JVM working directory to Agent reads

**AgentScope-Java is an open-source project. To involve a broader community, we recommend asking your questions in English.**

**Describe the bug**

`HarnessAgentBuilderSupport.resolveFilesystem()` has a default branch that creates a `new LocalFilesystemSpec()` without setting `project`. When `LocalFilesystemSpec.toFilesystem()` is called with a null `project`, it falls back to `System.getProperty("user.dir")` as the read-only lower layer of the `OverlayFilesystem`.

In CLI scenarios (e.g. Claude Code-style tools), `user.dir` is the user's working directory — this is reasonable. However, in non-CLI scenarios (e.g. web applications, embedded agents), `user.dir` points to the JVM's working directory, which is unrelated to the agent's intended project scope:

- **Development (IDE)**: `user.dir` = the IDE module directory, exposing all source code
- **Production (jar deployment)**: `user.dir` = the directory where the jar is launched from, potentially exposing deployment configs and sensitive files

This causes the Agent to be able to **read files it should not have access to** (source code, config files, etc.) through the filesystem lower layer.

This affects any caller that uses `HarnessAgent.builder().build()` without explicitly setting a filesystem spec — including `AgentCatalogService.buildAndRegisterUca()` in agentscope-builder.

**Root cause**: `LocalFilesystemSpec` carries a CLI-oriented default (`user.dir`) into the framework layer, and `resolveFilesystem()` unconditionally relies on it.

**To Reproduce**

Steps to reproduce the behavior:

1. Run `agentscope-builder` as a Spring Boot application in IntelliJ IDEA (or any IDE where `user.dir` = module source directory)
2. Create a user-custom agent via the catalog API (triggers `AgentCatalogService.buildAndRegisterUca`)
3. The agent's `OverlayFilesystem` lower layer (`LocalFilesystem`) is rooted at the IDE module directory
4. The agent can read `src/`, `pom.xml`, `application.yml`, and any other files in the module directory via filesystem tools

**Expected behavior**

When `project` is not explicitly set, the lower layer should default to the `workspace` directory itself (same root as the upper layer), rather than `user.dir`. This prevents unintended exposure of the JVM process's working directory.

CLI users who need their project directory as the lower layer should explicitly call `.project(Path)`.

**Error messages**

No error — this is a silent security issue. The agent can read files it should not have access to.

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

- AgentScope-Java Version: 2.0.0-RC5
- Java Version: 17
- OS: Windows (also affects macOS/Linux when running as a web server)

**Additional context**

Affected code path:

```
AgentCatalogService.buildAndRegisterUca()
→ HarnessAgent.builder().build() // no filesystem spec set
→ HarnessAgentBuilderSupport.resolveFilesystem()
→ default: new LocalFilesystemSpec().toFilesystem(workspace, nsFactory)
→ project == null → Paths.get(System.getProperty("user.dir")) // source/deployment directory
```

`BuilderConfig.configureAllAgents()` sets `LocalFilesystemSpec` for bootstrap-managed agents, but UCA agents created via `buildAndRegisterUca()` use a fresh `HarnessAgent.Builder` that bypasses the bootstrap configurator chain entirely.