Lists: CreateListAsync sends 2 of the 11 fields POST /api/lists accepts — initialRows would remove an N+1 #179

The gap

POST /api/lists accepts eleven fields. CreateListAsync sends two (title, isPublic):

public async Task CreateListAsync(string title, bool isPublic, …)
    => … new { title, isPublic } …

Found by #73's probing (PR #175), which needed source + githubRepo and discovered the rest.

The spec's request properties include title, description, isPublic, parentId, folderId, schema, source, githubRepo, githubSource, initialRows, messageId.

Why initialRows in particular matters

Three features currently create a list and then add rows one at a time:

• Powered Templates (AI: Powered Templates — generate a list from a description #174) — an AI powered_template artifact returns a full dsl and rows; today that's 1 create + N row POSTs.
• Materialize (Materialize ("Create from…") service layer + models #136) — listConfig.includeData seeds rows from a source, so the server already does this server-side; but a client building a list from data hits the same N+1.
• Any import path.

initialRows collapses that to one request. With no transaction across N+1 requests, a partial failure today leaves a list with some of its rows and no clean way to report that.

The other fields already have consumers waiting

So this isn't speculative: most of these are being added piecemeal by whichever issue needs them. Consolidating CreateListAsync into one options object would stop that.

Verified behaviour worth keeping

• source: "github" without githubRepo → 400 "githubRepo is required for GitHub-backed lists (format: owner/repo)", and creates nothing (verified — no orphan list).
• Create returns {message, data:{…}}, not {list:{…}}.

Acceptance criteria

• CreateListAsync takes an options object covering the accepted fields rather than growing positional parameters
• initialRows supported, and the callers above collapsed from N+1 to one request
• initialRows response shape verified live on a throwaway list before being typed strictly
• Existing two-argument callers keep working (overload or optional parameters)

Note

Filed from a review finding, not the parity audit. Low urgency — the current path works, it's just chatty and is being extended one field at a time by four different issues.