[drive] Large downloads restart from zero after transient failures; add Range-based resume

Summary

lark-cli drive +download is unreliable for large Drive files in automation, and a transient transfer failure forces the next attempt to restart from byte 0. The Drive download API already supports HTTP Range, but the CLI does not expose resume/checkpoint behavior.

This makes a single temporary network/CDN failure very expensive for files around 1 GB or larger.

Environment

• OS: Windows x64
• lark-cli: 1.0.83
• Authentication: user OAuth (identity: user)
• Resource: a regular file inside a Drive folder
• File type: RAR archive
• File size: 1,009,727,142 bytes (~963 MiB)

The real tenant URL, folder token, and file token are intentionally omitted because they belong to an internal corporate tenant. They can be shared privately with maintainers if needed.

Command

lark-cli drive +download `
  --file-token '<REDACTED_FILE_TOKEN>' `
  --output 'logs_20260811-170157.rar' `
  --overwrite `
  --json

Observed behavior

1. The folder can be inspected and listed successfully.
2. File metadata can be queried successfully.
3. During the problematic run, downloading the only file in the folder failed twice. Total elapsed time was about 12 minutes 50 seconds.
4. No reusable partial content remained after failure, so every retry started from byte 0.
5. The temporary output provided no useful progress signal and the automation ultimately only knew that the download failed.
6. Running the same download command against the same token later succeeded and downloaded all 1,009,727,142 bytes in about 255 seconds.

This strongly suggests an intermittent transport/CDN failure rather than an invalid token, missing permission, insufficient disk space, or an unsupported file type.

For archive files, drive +preview --type source_file is not a fallback. The preview API returns:

{
  "code": 90003033,
  "message": "file type does not support preview"
}

Impact

In unattended agents and CI-style workflows, retrying a large file from byte 0 wastes substantial time and bandwidth. Multiple transient failures can prevent the downstream analysis from receiving any logs at all.

Expected behavior / request

Please add resumable large-file downloads to drive +download, for example:

• --continue / --resume option.
• Persist a .partial file plus checkpoint metadata.
• Resume with Range: bytes=<downloaded>- after validating the remote file identity/size/version.
• Preserve partial data after transport errors or process interruption.
• Bounded retries with exponential backoff.
• Report downloaded bytes, total bytes, speed, and ETA on stderr.
• Preserve and return the underlying transport error in JSON.
• Optionally support configurable chunk size and integrity verification.

The official Drive download API documents partial downloads via the HTTP Range header and HTTP 206 responses:

https://open.feishu.cn/document/server-docs/docs/drive-v1/download/download

Suggested acceptance cases

1. Interrupt a 1+ GB download after several hundred MB, rerun with --continue, and verify that only the remaining bytes are requested.
2. Simulate a connection reset and verify automatic bounded resume.
3. Verify that a changed remote file invalidates stale checkpoint data.
4. Verify that a server without Range support safely falls back to a full download.
5. Verify machine-readable progress and the original transport error in JSON output.

Start at the lark-cli drive +download command and read the Drive download API documentation linked in the issue, focusing on Range requests and HTTP 206 responses. Use the five suggested acceptance cases as the validation plan: interruption and transport-reset resume, stale-checkpoint invalidation, no-Range fallback, and machine-readable progress with the original transport error.