Lists: creation options the API accepts but the app drops (`parentId`, `folderId`, `messageId`, `initialRows`, `metadata`)

[Adron]

Part of #49 — Lists parity gaps: GitHub-backed lists, saved views, view modes and collaborative editing

CreateListRequest sends only title, description, schema, isPublic.

• parentId — child lists form a tree with breadcrumb navigation on the web; Android cannot
  set a parent at creation.
• messageId — "Create list from message": the list-plus icon on any message creates a list
  using that message as the description, with a suggested name. (Related to, but distinct from,
  the Create-from epic.)
• initialRows — starter rows at creation, which Powered Templates depends on.
• metadata / source — pass-through fields.
• Also expose the From Template tab the web offers on list creation. There is no list-template
  endpoint in the OpenAPI spec, so confirm with the owner where those templates come from before
  building.

Tests: each field reaches the request; parent breadcrumb navigation.

---

Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.

[Adron]

Implemented in #98 (branch issue/54-list-creation-options). Closing here — review and any follow-up happens on the PR.

Three things need your input, carried into the PR so they are not lost:

1. From Template tab was not built — as the issue suspected, there is no list-template endpoint anywhere. The spec has only /api/documents/templates, /api/documents/templates/seed-defaults and /api/documents/from-template, and the help centre has no list-template page. Where do the web's list templates come from?
2. initialRows shape is unverified. The generated spec types it as "type": "string", and the human-written reference never mentions it. It is modelled as an array of flat column-keyed objects, matching how POST /api/lists/{id}/data serialises a row. Worth confirming before AI: Powered Templates tab on list creation #8 (Powered Templates) depends on it.
3. folderId is not a documented create field — it is a real column, but folder placement is documented on PUT /api/lists/{id} instead. Included as the issue asked, with a KDoc caveat.

Also corrected along the way: CreateListRequest.schema was typed String?, but the help reference is explicit that POST /api/lists takes the DSL as an object (the comma-separated string form belongs to PUT /api/lists/{id}/schema). No caller ever set it, so the fix is behaviour-neutral.

Not done, worth its own issue: PUT /api/lists/{id} accepts parentId, so re-parenting an existing list is still unsupported.