[Feature] base v3: support field filtering in +record-list / add +record-query for composite queries

[0xqige]

Background

The lark-cli base v3 shortcut commands have a capability gap for the common use case of "locating a record by field value": callers are forced to iterate the whole table.

1. +record-list has no filter parameter — only --offset / --limit pagination is available, requiring a full-table scan.
2. The filter set by +view-set-filter is NOT applied when reading via +record-list --view-id
   - +view-get-filter can read back the filter, confirming it was persisted on the view
   - However, +record-list --view-id still returns all records, which contradicts the behavior of filtered views in the Lark web UI
3. +data-query is not a viable substitute
   - It's an aggregation API and returns main_data, not raw records — so there is no way to obtain a record_id
   - Formula fields (including user-defined "Record ID" formulas) are excluded from the data-query field-type allowlist, so there's no workaround

Reproduction

   1. Create a view and set a filter
  lark-cli base +view-create \
    --base-token <token> --table-id <tbl> \
    --json '{"name":"tmp","type":"grid"}'
  # → returns view_id = vewXXX

  lark-cli base +view-set-filter \
    --base-token <token> --table-id <tbl> --view-id vewXXX \
    --json '{"logic":"and","conditions":[["Name","==","TargetRow"]]}'
  # → filter is written successfully

  2. Read records via the view
  lark-cli base +record-list \
    --base-token <token> --table-id <tbl> --view-id vewXXX --limit 10
  # → actually returns ALL records; the filter is ignored

Proposal

P0 — add --filter to +record-list

Server-side filtering that returns record details (including record_id):

lark-cli base +record-list
--base-token --table-id
--filter '{"logic":"and","conditions":[["Name","==","TargetRow"]]}'

Condition syntax should reuse the existing +view-set-filter tuple form ([field, operator, value]) for consistency.

P1 — introduce +record-query for composite queries

Support filter + sort + field projection + limit in one call:

lark-cli base +record-query
--base-token --table-id
--json '{
"filter": {"logic":"and","conditions":[["Status","==","Active"]]},
"sort": [{"field":"CreatedTime","order":"desc"}],
"fields": ["Name","Owner","Status"],
"limit": 50
}'

P2 — make +record-list --view-id honor the view's own filter/sort

Align the API behavior with the Lark UI to remove the silent semantic gap between API and UI.

Alternatives Considered

The official bitable/v1 records/search endpoint already supports filter natively. If server-side filtering won't be added directly to the v3 API, the shortest path is to wrap bitable/v1 records/search under
lark-cli base as a new v3-style shortcut command, shielding users from the underlying API version difference.

Expected Benefits

• Locating a single record_id by field value: 1 API call, down from ceil(totalRecords / 200) calls today
• Large tables (>10k rows): latency correlates with result-set size, not total row count
• Eliminates the hidden pitfall where "the API accepts a view filter but doesn't apply it"
• Agents / skills built on top of lark-cli can implement natural-language record lookup much more cleanly

Environment

• lark-cli: 1.0.6 (also reproducible on 1.0.14)
• API: base v3