+form-submit: 800004006 option not found for dynamic_options_source selects

Summary

lark-cli base +form-submit (and the underlying POST /open-apis/base/v3/bases/tables/forms/submit) returns 800004006 / option "NAME" not found in field options for select questions whose field uses dynamic_options_source.

The same option name is present in +form-detail / +field-get (options[].name). No record is created. This happens with both --as bot and --as user.

Related but not the same as #222 (+record-upsert skip with UNSUPPORTED: select field with dynamic options cannot be written through OpenAPI). Here the form-submit path does attempt convert and fails.

Environment

• lark-cli 1.0.95
• Endpoint: POST /open-apis/base/v3/bases/tables/forms/submit
• Identity: tenant token (--as bot) and user token (--as user)
• Scope: base:form:update (request is accepted; failure is option convert, not 404 / permission)

Repro

1. A shared Base form whose select questions use dynamic_options_source (options pulled from another table). Some questions also have UI cascade / filter conditions.
2. +form-detail --share-token SHARE_TOKEN — the target option names appear in questions[].options[].name (shape is {hue, lightness, name}; no id / option_id).
3. Submit those names as cell values (single-select string, multi-select string array), matching the form-submit skill:

lark-cli base +form-submit \
  --as bot \
  --share-token SHARE_TOKEN \
  --json '{"fields":{"Size":["720x1280"],"Duration":["30s"],"Type":"TP"}}' \
  --yes

(Size / Duration / Type stand in for the real question titles.)

Actual

HTTP 200, code: 800004006, type: validation_error, retryable: false. The message rotates across dynamic-option fields depending on payload / JSON key order, for example:

• field[Size] convert failed: option "720x1280" not found in field options
• field[Duration] convert failed: option "30s" not found in field options
• field[Type] convert failed: option "TP" not found in field options

Example data.error:

{
  "code": "800004006",
  "hint": "请检查请求参数是否合法",
  "message": "field[Duration] convert failed: [code=800004006] option \"30s\" not found in field options",
  "retryable": false,
  "type": "validation_error"
}

CLI --dry-run rewrites content through a Go map[string]interface{}, so key order is not preserved. A raw HTTP POST with insertion-ordered JSON (parent questions before child questions) still failed on a later dynamic-option field (30s). So this is not only a CLI map-ordering issue.

Expected

Either:

1. Accept option names that form-detail already lists; or
2. Document that dynamic_options_source selects cannot be written via form-submit (same class of limit as #222), and return a stable unsupported error instead of "option not found".

+form-submit / field-schema currently say:

• submit values as option names from form-detail
• cascade / referenced-option conditions are UI-only (OpenAPI cannot read/create/update them)

They do not say form-submit convert will reject those names.

Extra notes (no tenant identifiers)

• form-detail filter.conditions[].value for some cascade parents is [] even though the UI has conditions — consistent with the UI-only cascade note in field-schema.
• Options have no option_id to send instead of name.
• Static (non-dynamic) selects in the same payload were not the failing field.
• No row is inserted; the failure is pre-insert convert.

Start at the +form-submit command and the skills/lark-base/references/lark-base-form-submit.md guidance, then trace how select values are converted for dynamic_options_source fields. Reproduce with the documented --share-token payload and verify that names from +form-detail are accepted, or that the command returns a stable unsupported error instead of 800004006.