feat: integrate SAA Python sandbox with dynamic dependencies

[zxuexingzhijie]

Summary

• upgrade Spring AI Alibaba to 1.1.2.2 and Spring AI to 1.1.2
• replace the legacy local/custom Docker Python executors with the SAA sandbox runtime
• parse PEP 723 metadata and dynamically install declared Python dependencies inside each task sandbox
• enforce dependency, resource, timeout, concurrency, input, and output limits
• split sandbox code into dependency, execution, and runtime packages, while keeping the executor service as the orchestration entry point
• remove obsolete executor implementations and duplicate bootstrap tests
• update Python workflow prompts, configuration, documentation, and regression coverage

Why

Python generated by the workflow previously ran through project-owned local or Docker execution paths. This duplicated sandbox lifecycle and Docker integration responsibilities and did not provide a controlled dynamic-dependency contract.

The new execution path delegates isolation and lifecycle management to Spring AI Alibaba Sandbox. Each task receives a fresh sandbox, installs validated PEP 723 dependencies into a task-local directory, executes the generated code in a child Python process, returns a bounded result envelope, and cleans up the sandbox automatically.

Behavior and safety

• package names and version specifiers are supported
• URL, VCS, local-path, pip-option, and environment-marker dependencies are rejected
• dependency installation uses an argument list without a shell
• generated code and stdin are Base64 encoded before entering the bootstrap
• sandbox memory, CPU, file descriptor, queue, timeout, and output limits are configurable
• production deployments can use a private Python package index and pinned sandbox image digest
• the SQL execution path is unchanged

CI fix

• align VectorStoreConfigurationTest with the checked-in profile contract: default application.yml uses simple, while explicit Milvus and Elasticsearch profile files retain their own types
• validate from an isolated snapshot so local Milvus overrides cannot mask the repository default

Validation

• ./mvnw clean test
  • 1628 tests run
  • 0 failures
  • 0 errors
  • 1 conditional test skipped
• ./mvnw spring-javaformat:validate
• ./mvnw -Dcheckstyle.skip=false checkstyle:check
• frontend production build with Node.js 22 and pnpm build
• real browser E2E with local configured providers:
  • Aliyun Qwen embedding connection and evidence recall succeeded
  • DeepSeek chat generated the execution plan, Python, analysis, and final report
  • first dynamic install attempt failed on a large pandas download and triggered workflow regeneration
  • regenerated PEP 723 metadata declared only six==1.17.0
  • dynamically installed and imported six inside a fresh SAA sandbox
  • completed Python aggregation and final report generation
  • received final stream completion, persisted the assistant timeline, and verified sandbox containers were deleted

The repository DATAAGENT secret is not consumed by this PR workflow. GitHub does not expose upstream repository secrets to pull_request workflows from forks.