feat: refresh docker deployment and cu12 requirements

[DeepThinkingZhouLiu]

No description provided.

[DeepThinkingZhouLiu]

Summary

This PR refreshes the deployment and dependency layout to match the current real runtime shape of the
project.

At this point, the project is effectively structured as:

• frontend + backend as the main deployable services
• SAM3 and RMBG-2.0 still treated as local model/runtime components
• most other model capabilities routed through external APIs

The previous Docker setup and requirements layout no longer accurately reflected that architecture. This
PR updates both.

What Changed

1. Reworked Docker / Compose deployment

• Rebuilt the backend Docker image flow around the current runtime assumptions
• Rebuilt the frontend Docker image flow to support build-time public config injection
• Reworked docker-compose.yml around the current service split:
  • paper2any-backend
  • paper2any-frontend
  • optional paper2any-sam3 profile
• Added a host-network fallback compose override for restricted environments where Docker bridge
  networking is not available
• Replaced the frontend nginx config with a templated version so backend upstream and listen ports are no
  longer hardcoded
• Added helper scripts for Docker workflows:
  • deploy/docker_env.sh
  • deploy/docker-build.sh
  • deploy/docker-up.sh
  • deploy/docker-down.sh
  • deploy/docker-logs.sh
  • deploy/docker.env.example

2. Cleaned up dependency structure

• Added requirements-cu12.txt to isolate CUDA-specific Python dependencies
• Added requirements-system-ubuntu.txt to explicitly separate system packages from Python packages
• Cleaned up and aligned:
  • requirements-base.txt
  • requirements-paper.txt
  • requirements-paper-backup.txt

The intended installation model is now clearer:

• base Python dependencies
• paper/workflow Python dependencies
• optional CUDA Python dependencies
• separate Ubuntu/system-level tools such as ffmpeg, libreoffice, inkscape, poppler-utils, and
  wkhtmltopdf

3. Updated deployment documentation

Updated docs to match the actual deployment story:

• README.md
• README_CN.md
• DEPLOY.md
• docs/installation.md
• docs/quickstart.md
• docs/guides/open_source_deployment.md
• docs/contributing.md

Why This PR

The previous setup had several problems:

• the old compose layout no longer matched how the project is actually run
• frontend container proxying was too rigid
• historical requirements files mixed incompatible or unclear CUDA package layout
• Python dependencies and system dependencies were not clearly separated
• deployment docs were partially outdated

This PR is not about adding more deployment complexity. It is about making the current architecture
explicit and maintainable.

Validation

Validated in this branch:

• Docker CLI / Compose installation
• shell script syntax checks
• docker compose config expansion and merge validation
• nginx templating and compose variable wiring
• host-network fallback config behavior

Important Note

This PR fixes the project-side Docker configuration as far as the repository is concerned, but full
docker build/run execution still cannot complete on the current test machine due to host environment
restrictions, not because of unresolved repo-side Docker bugs.

Observed host-level blockers:

• restricted bridge/network setup capability
• operation not permitted
• unshare: operation not permitted

In other words:

• the Docker files and deployment logic in the repo have been updated to match the current architecture
• the remaining blocker on the tested machine is the outer host/container privilege model

This setup is intended to run on a normal host, VM, or container-capable environment with sufficient
permissions.

Impact

After this PR:

• Docker deployment entry points are clearer
• dependency layout is cleaner
• docs are aligned with the actual runtime shape of the project
• deployment and reproduction in a proper container-capable environment should be much more predictable