feat(base): support Base Home APIs and home-level shortcuts

Summary

Please add support for Base Home APIs to lark-cli, including registered API schemas and agent-friendly shortcuts for Base Home discovery and governance.

Terminology: Base Home is the official product name. If the upstream OpenAPI schema uses a different resource or field name (for example, workspace), native commands and flags should mirror that schema, while user-facing help and skill documentation should describe the feature as Base Home.

The current base command already provides broad coverage inside a known Base token (tables, fields, records, views, dashboards, workflows, forms, roles, and permissions), but it does not expose Base Home operations.

Environment

• lark-cli version: 1.0.76
• Verified with: lark-cli base --help

Problem

In tenants that organize multiple Bases through Base Home, agents and automation currently need pre-recorded Base tokens or manual UI navigation before they can operate.

There is no obvious CLI workflow to:

1. Enumerate Base Home resources accessible to the current user or app.
2. Get Base Home metadata and permission information.
3. Enumerate the Bases presented or organized in Base Home.
4. Place a newly created Base into a specified Base Home location, or move/copy an existing Base there, when supported by the upstream OpenAPI.
5. Inspect or manage Base Home members and roles, when supported by the upstream OpenAPI.

This creates a discovery gap between tenant-level organization and token-level Base operations. It is especially limiting for AI agents that should discover resources through stable identifiers instead of relying on manually maintained links.

Requested capability

Phase 1: read-only discovery

Please register the official Base Home API surface first. Semantic shortcuts could follow names such as:

lark-cli base +home-list --as user --page-all
lark-cli base +home-get <official-id-or-token-flag> --as user
lark-cli base +home-base-list <official-id-or-token-flag> --as user --page-all

The exact identifier flag should follow the official OpenAPI schema rather than inventing a space_id. Suggested structured output should include stable identifiers, display names, access/role information, pagination metadata, and Base tokens/URLs where the upstream API returns them.

Phase 2: governed writes

If supported by the official OpenAPI, consider commands for creating, moving, or copying a Base into a Base Home location and for managing Base Home membership. Command and flag names should match the official schema; for example:

lark-cli base +base-create <official-home-location-flag> ...
lark-cli base +base-move --base-token <token> <official-home-location-flag>
lark-cli base +home-member-list <official-id-or-token-flag>
lark-cli base +home-member-add <official-id-or-token-flag> ...
lark-cli base +home-member-remove <official-id-or-token-flag> ...

Write operations that change placement, membership, or permissions should follow the CLI's existing risk classification, --dry-run, and confirmation-gate conventions.

Expected CLI integration

• Use Base Home consistently in user-facing command descriptions, help text, skill documentation, and examples.
• Preserve official OpenAPI resource and field names in native commands and machine-readable output.
• Support both --as user and --as bot where the upstream API allows them.
• Expose required scopes and identity limitations in --help and the lark-base skill.
• Preserve standard JSON success/error envelopes.
• Support normal pagination flags, including --page-all, where applicable.
• Register the underlying schemas so users can still call native resource commands before every shortcut is implemented.
• Clearly distinguish the Base Home resource identifier returned by the API from a Base token/app token.

Acceptance criteria

A user or agent can start without a pre-recorded Base token and:

1. Enumerate accessible Base Home resources through the official OpenAPI.
2. Select one using the stable identifier returned by that API.
3. Enumerate the Bases associated with it.
4. Continue with existing Base commands using a returned Base token.

A read-only first release would already close the main discovery gap; write-side Base Home management can follow separately if needed.

If the Base Home API is not yet publicly exposed by the upstream OpenAPI, the first useful outcome is to document that dependency explicitly and avoid implementing against undocumented private endpoints.

Start with lark-cli base --help and the existing Base command, schema-registration, shortcut, pagination, risk-classification, and lark-base skill conventions. First verify whether the official OpenAPI exposes Base Home, including identifiers, scopes, identity support, and read-only operations; do not use undocumented endpoints. Done means a supported read-only workflow can list Base Home resources, select one by its returned stable identifier, list its Bases, and continue with an available Base token.