Refactor API layer and add real async job progress for training requests

[ISEEKYAN]

Background

While reading the current server implementation, I noticed two areas that may become increasingly hard to maintain as the API surface grows.

1. app.py is becoming too large and repetitive

src/verl_mint/app.py currently contains a large amount of route registration, request/response adaptation, compatibility handling, in-memory state management, checkpoint bookkeeping, future wrapping, and helper logic in one file.
A lot of the route code is also boilerplate-like:

• duplicated /api/v1/* and legacy route bindings
• repeated conversion between Pydantic schemas and backend/service payloads
• repeated future wrapping
• repeated checkpoint/session/sampler response shaping
• version-specific behavior based on route path checks
  This makes the API layer harder to review and harder to extend safely.
  Suggested direction:
• Split app.py into smaller route modules by domain, such as sessions, models, training, sampling, checkpoints, rollouts, futures, etc.
• Move compatibility-specific response shaping into presenter/adapter helpers.
• Consider defining repetitive endpoint mappings in a declarative config, then auto-registering or generating simple route handlers where possible.
• Keep route handlers thin: validate request, call service layer, format response.

2. Core training APIs appear synchronous and lack progress visibility

For core training operations such as forward_backward_ppo, the current HTTP handler appears to execute the backend training call synchronously, then only after completion wraps the completed result into a future-like request_id.
That means the client experience is roughly:

1. POST /forward_backward_ppo
2. server blocks until training finishes
3. server returns request_id
4. client calls retrieve_future
5. result is usually already complete
   This preserves a future-shaped API, but it is not a true async job model. For long-running training operations, the first request may hang for a long time with no progress information, which can feel risky or confusing to users.
   Suggested direction:

• Change long-running training endpoints to submit a background job and return a token/request ID immediately.
• Let clients poll by token to retrieve job status.
• Expose useful status fields, for example:
  • queued / running / succeeded / failed / cancelled
  • progress percentage or completed steps / total steps
  • current phase
  • latest metrics
  • error message if failed
  • timestamps
• Keep final result retrieval compatible with the current future semantics where possible.
• Optionally support cancellation and server-side timeout handling.

Why this matters

These two issues are connected: as more training operations become long-running and stateful, keeping all route/state/future logic inside app.py will make it harder to provide robust async behavior, progress reporting, retries, cancellation, and persistence.
A cleaner split between API routing, job management, progress state, and backend execution would make the system easier to evolve.

@ISEEKYAN

先声明：我是这个项目的真实用户。大概大半年前开始使用的，当时觉得还不错，也确实给点了 Star——一颗货真价实的星。

但最近我发现了一些让我非常不舒服的事情。

Star 14918 但 fork 仅 46。唯一的活动就是给本项目点了星。

你知道这意味着什么吗？意味着我给的那颗真心的 Star，和几千个机器人点的假 Star 并排在一起。我的认可被稀释到了几乎为零的浓度。

最让我不能接受的是：你们在欺骗新用户的同时，也在消费像我这样真实用户的信任。

作为一个真实用户，我的诉求很简单：

• 清理掉明显的假账号
• 给社区一个公开说明
• 用正当方式推广
• 坦诚面对问题
• 写个 postmortem

如果你们不处理，我会撤回我的 Star，然后再也不会用这个项目。期待你们的正面回应。社区在看着。
违规处处皆是，举报发 GitHub，违规流量终被清理，项目封禁。