[bug] docs +media-download returns HTTP 403 on docx/wiki images — undocumented +media-preview fallback works

Summary

docs +media-download returns HTTP 403 when downloading images embedded in a docx/wiki document (e.g. <image token=X .../> references inside a markdown body returned by docs +fetch --api-version v1). The same media downloads successfully via docs +media-preview. This appears to be because +media-download doesn't append the extra={"doc_id":"...","doc_type":"docx"} query parameter that the Drive Media Download API requires for docx-hosted media.

PR #628 adds --extra to +media-download but only for bitable advanced-permission attachments (payload shape {"bitablePerm":{...}}); it doesn't help docx/wiki images.

Repro

# Fetch a public-readable wiki doc and pick any <image token=.../> from the body:
lark-cli docs +fetch --api-version v1 --doc 'https://<tenant>.feishu.cn/wiki/<wiki-token>' --as user --jq .data.markdown | grep -o 'token="[^"]*"' | head -1
# → token="FSZbbG9TAoYDWoxxgKUcbevznYc"  (example)

# This 403's:
lark-cli docs +media-download --token FSZbbG9TAoYDWoxxgKUcbevznYc --output ./img --type media --as user
# → "type":"network","message":"download failed: HTTP 403"

# This succeeds:
lark-cli docs +media-preview --token FSZbbG9TAoYDWoxxgKUcbevznYc --output ./img --as user
# → "ok":true, "saved_path":"./img.png", "size_bytes":255890

Both calls are made with the same user identity (has docs:document.media:download scope).

Why this is confusing

• +media-download is the obvious entry point (its name says "download").
• The skill docs (skills/lark-doc/references/lark-doc-media-download.md) only mention 403 as a one-line aside under "排障" → "可以改成调用 docs +media-preview", easy to miss.
• The +media-preview name suggests a downscaled / thumbnail variant, but it actually returns the full-resolution original (verified: a 2560×1305 source returned as 2560×1305).
• Adjacent debugging path (raw api GET /open-apis/drive/v1/medias/<token>/download with manually-constructed extra={"doc_id":"...","doc_type":"docx"} parameter) appears to reach the API successfully but lark-cli mishandles the binary response: "API returned an empty JSON response body" error, and --output doesn't write the file. Separate-but-related issue.

Suggested fixes

A few options, in increasing order of effort:

1. Document the fallback inline: bump +media-preview ahead of "use this for 403 cases" in skills/lark-doc/SKILL.md's decision rules.
2. Auto-fallback: when +media-download receives 403 on --type media, retry the request via the media-preview endpoint (same target, different path) before surfacing the error.
3. Match upstream API behavior: have +media-download synthesize extra={"doc_id":"<resolved>","doc_type":"docx"} automatically when the token can be traced back to a docx via --doc context, similar in spirit to what PR #628 does for bitable.

(2) gives the best UX — users wouldn't have to know about +media-preview at all.

Versions

• lark-cli v1.0.29 (latest as of 2026-05-13)
• macOS 25.3.0 darwin/arm64
• Verified against multiple wiki docs in a public-readable space.

Start by reproducing the 403 with docs +media-download and the successful result from docs +media-preview. Read skills/lark-doc/SKILL.md, skills/lark-doc/references/lark-doc-media-download.md, and PR #628 to understand the documented and existing media paths. Before coding, clarify which suggested fix is wanted; done should include a verified resolution for docx/wiki image downloads without breaking existing media behavior.