Drive sync shortcuts declare a scope that does not authorize folder listing

Summary

drive +push, drive +pull, drive +status, and drive +sync declare
drive:drive.metadata:readonly for recursively listing Drive folders.

However, the shared listing implementation calls:

GET /open-apis/drive/v1/files

The API does not accept drive:drive.metadata:readonly. At runtime it can fail
with 99991679, reporting these alternative scopes:

• drive:drive
• drive:drive:readonly
• space:document:retrieve

As a result, the shortcut scope preflight succeeds, but execution immediately
fails while listing the target folder.

Version

Confirmed in the latest main commit:

• Commit: 4a56748bfa941ff0ee0bfec92e65acac427732b0
• Release: v1.0.72

Steps to reproduce

1. Authorize a user with the scopes currently declared by drive +push:

   • drive:drive.metadata:readonly
   • drive:file:upload
   • space:folder:create

2. Run:

   lark-cli drive +push \
     --local-dir ./local-dir \
     --folder-token <folder-token> \
     --as user
   

3. The shortcut passes its declared-scope preflight, walks the local directory,
   and fails when listing the Drive folder.

Actual behavior

Walking local: ./local-dir
Listing Drive folder: <masked>

{
  "ok": false,
  "identity": "user",
  "error": {
    "type": "authorization",
    "subtype": "missing_scope",
    "code": 99991679,
    "message": "unauthorized: user authorization does not cover the required scope(s): drive:drive, drive:drive:readonly, space:document:retrieve",
    "missing_scopes": [
      "drive:drive",
      "drive:drive:readonly",
      "space:document:retrieve"
    ]
  }
}

The generated hint asks the user to authorize all three scopes:

lark-cli auth login --scope "drive:drive drive:drive:readonly space:document:retrieve"

These are alternative scopes accepted by the API, so requesting all of them is
unnecessarily broad.

Expected behavior

Before execution, the shortcut should require a scope that actually authorizes
GET /open-apis/drive/v1/files.

If the API exposes several alternative scopes, the CLI should select or
recommend one supported least-privilege scope instead of requiring all
alternatives.

The command documentation should describe the same effective scope requirement.

Relevant code

The affected shortcuts currently declare
drive:drive.metadata:readonly:

• shortcuts/drive/drive_push.go
• shortcuts/drive/drive_pull.go
• shortcuts/drive/drive_status.go
• shortcuts/drive/drive_sync.go

They all call the shared recursive listing helper:

• shortcuts/drive/list_remote.go
• listRemoteFolderEntries
• GET /open-apis/drive/v1/files

The documentation repeats the same scope assumption:

• skills/lark-drive/references/lark-drive-push.md
• skills/lark-drive/references/lark-drive-pull.md
• skills/lark-drive/references/lark-drive-status.md

The generic missing-scope hint currently joins every reported scope with spaces:

• internal/errclass/classify.go
• PermissionHint

Suggested fix

1. Determine which least-privilege scope should be used for
   drive.files.list, considering that drive:drive and
   drive:drive:readonly may be unavailable under some tenant policies.
2. Update the four affected shortcuts and their documentation.
3. If the scope model supports alternatives, represent this requirement as
   “one of” instead of adding every candidate to the conjunctive Scopes list.
4. Update the missing-scope hint so API-provided alternatives do not produce an
   “authorize everything” command.
5. Add regression coverage where folder listing returns 99991679 even though
   drive:drive.metadata:readonly passed shortcut preflight.

Start with the four shortcut files and shortcuts/drive/list_remote.go to trace the declared scopes into listRemoteFolderEntries and the files endpoint. Then inspect internal/errclass/classify.go and PermissionHint for how reported alternatives are joined, followed by the three drive reference documents. Done means preflight matches the effective least-privilege requirement, alternatives are not treated conjunctively, documentation agrees, and regression coverage covers error 99991679 after the existing preflight.