[Base] Support creating traditional form views (`view_type=form`) separately from collection forms

Summary

lark-cli currently has no typed command for creating a traditional Base form view — the view that appears in Base with the Edit form / Fill form tabs.

This is different from the newer collection form created by base +form-create, but the current command help conflates the two resources.

Current behavior

base +view-create documents the supported types as:

grid, kanban, gallery, calendar, gantt

and explicitly says:

Do not pass form as a view type; form views are managed through form commands.

However, the form commands create/manage a different resource:

lark-cli base +form-create \
  --base-token <base_token> \
  --table-id <table_id> \
  --name "Progress update"

This calls:

POST /open-apis/base/v3/bases/:base_token/tables/:table_id/forms

and creates the newer collection form, not a traditional form view.

Meanwhile, a dry run using type=form with +view-create produces a Base v3 request:

lark-cli base +view-create \
  --base-token <base_token> \
  --table-id <table_id> \
  --json '{"name":"Progress update","type":"form"}' \
  --dry-run

POST /open-apis/base/v3/bases/:base_token/tables/:table_id/views

So the command does not reject the payload during JSON validation, but its documented contract excludes form and it routes through the Base v3 view endpoint.

Why this is a CLI coverage gap

The public Bitable v1 API explicitly supports creating a traditional form view:

POST /open-apis/bitable/v1/apps/:app_token/tables/:table_id/views

{
  "view_name": "Progress update",
  "view_type": "form"
}

Official documentation:

• Create view (view_type=form): https://open.feishu.cn/document/server-docs/docs/bitable-v1/app-table-view/create
• Get traditional form metadata: https://open.feishu.cn/document/server-docs/docs/bitable-v1/form/get
• Update traditional form metadata: https://open.feishu.cn/document/server-docs/docs/bitable-v1/form/patch-2
• List traditional form fields/questions: https://open.feishu.cn/document/server-docs/docs/bitable-v1/form/list
• Update traditional form fields/questions: https://open.feishu.cn/document/server-docs/docs/bitable-v1/form/patch

For these traditional forms, form_id is the same identifier as the form view's view_id.

Existing workaround

The traditional form view can currently be created only through the raw API escape hatch:

lark-cli api POST \
  '/open-apis/bitable/v1/apps/<app_token>/tables/<table_id>/views' \
  --data '{
    "view_name": "Progress update",
    "view_type": "form"
  }' \
  --as user

Its questions and metadata can then be configured through additional raw bitable/v1 calls. This works, but users and agents must already know that two different form resource models exist.

Proposed solution

Either:

Option A: Extend +view-create

Allow type=form and route that payload to the compatible Bitable v1 endpoint.

Option B: Add explicit traditional-form commands

For example:

+form-view-create
+form-view-get
+form-view-fields-list
+form-view-field-update
+form-view-update

This may be clearer because +form-create is already used for the newer collection-form resource.

Documentation requirement

Whichever command shape is chosen, CLI help and the lark-base skill should explicitly distinguish:

1. Traditional form view: a table view; form_id == view_id; has Edit form / Fill form UI; backed by bitable/v1 form-view APIs.
2. Collection form: created by Base v3 /forms; managed by the existing +form-* commands.

The current wording — “form views are managed through form commands” — is misleading because those commands create a different form type.

Acceptance criteria

• A typed CLI command can create a traditional form view and returns its view_id / form_id.
• The resulting Base UI exposes the traditional Edit form / Fill form experience.
• Help and skill documentation clearly differentiate traditional form views from collection forms.
• Tests cover endpoint routing and payload conversion (name/type vs. view_name/view_type).
• Existing collection-form commands remain backward compatible.

Environment

• Reproduced with lark-cli v1.0.74.
• Checked the repository and latest release v1.0.76; the traditional form-view path is still not exposed as a typed command.

Start with the existing +view-create and +form-create command implementations and their help text, then compare their Base v3 routes with the documented Bitable v1 form-view endpoint. Decide whether to extend +view-create or add explicit form-view commands. Done means a typed create path returns view_id/form_id, help and the lark-base skill distinguish both form resources, and tests cover endpoint routing, payload conversion, and collection-form compatibility.