fix(pd): protect streaming continuations from admission timeouts

[sufubao]

问题与改动

PD Decode 因 token 容量不足结束当前分段后，Master 会重新提交续跑。此前续跑仍可能因 shm/Router 资源等待或固定握手超时触发 busy；由于回答已经输出 token，最外层不能从头重试，最终导致流式回答中断。

本改动保留现有 PD 分段机制，让续跑作为已接纳回答的内部恢复操作继续执行：

• 增加仅由 Master 设置的 pd_is_continuation，在 shm 分配、Router 和推理调度中实行“续跑 > cache 优先新请求 > 普通新请求”。shm 优先级检查与整组分配使用跨 HTTP worker 的共享锁，等待期间不持有部分槽位。
• 续跑资源等待默认改为无限等待，并取消续跑的固定 60/180 秒握手上限。若显式配置有限资源等待时间，只重试尚未输出 token 的失败续跑分段，清理旧尝试并退避，保留已输出内容和剩余 token 额度。
• 通过请求总时间预算限制所有分段与重试；关闭流、取消请求或节点断连时终止等待并清理资源。保留最外层已输出 token 后禁止从头重试的保护。
• 更新中英文配置说明。

配置与部署

• LIGHTLLM_PD_NODE_CONTINUATION_RESOURCE_WAIT_TIMEOUT_SECONDS 默认由 60 改为 -1；显式设置非负值时，续跑 busy 进入内部重试。
• 新增 LIGHTLLM_PD_REQUEST_TIMEOUT_SECONDS，默认 1800 秒，负数禁用；预算不会在分段或 token 输出后重置。
• 新增共享请求结构字段，部署时需要统一版本重启 Master、P/D 节点及 worker。
• 此改动不替代客户端、网关及健康检查自身的超时设置。

验证

python -m pre_commit run --from-ref upstream/main --to-ref HEAD

Black、flake8 检查通过。尚未进行真实 P/D GPU 服务验证或性能压测。