editor: multipart events need a way to add several non-regular dates without recreating the form

[hhkaos]

Context

Came up while designing the "Part of (series)" UX (see the series-linking
wizard work). `partOf.type: "multipart"` covers an event held across
several non-consecutive, not-necessarily-regular dates — e.g. a
3-session study jam on arbitrary Saturdays, or day 2/3 of a conference.

Per OTE's spec, each session is still its own document ("un documento =
una ocurrencia"), all pointing at the same `partOf.id`.

Current gap

The editor's only batch-generation mechanism today is "+ Add recurrence"
(renderRecurrenceRows in apps/editor/src/ui/form.ts), and it is
strictly rule-based: daily/weekly/monthly/yearly + interval
(apps/editor/src/lib/recurrence.ts). There is no way to enter a plain
list of arbitrary dates.

Two workarounds exist today, neither good for a genuinely irregular
multipart series:

1. Approximate with a rule (e.g. weekly) and uncheck the occurrences
   that don't apply in the generation-review dialog (that per-occurrence
   checkbox list already exists, reused from ICS/JSON-LD import) — works
   only when the real dates happen to be a subset of a regular pattern.
2. Use "Create event" N times by hand, re-entering the same 4
   partOf.* fields (id/name/url/type) on every single occurrence —
   tedious and error-prone (easy to typo the shared partOf.id, which
   breaks the grouping silently).

Suggested direction (not scoped/designed yet)

A dedicated "+ Add session" repeater for the multipart case — plain
date+time rows instead of a frequency rule — reusing the same batch
generation/review/submission pipeline recurrence rows already use
(onGenerateRecurrenceSeries / submitRecurringBatch in
apps/editor/src/main.ts), so all sessions share one partOf filled in
once.

Deliberately left open-ended — needs its own UX pass (where it lives in
the form, how it interacts with the "Part of" series-linking wizard once
that lands, whether it's its own row type or a mode of the existing
recurrence rows) rather than being bundled into the series-identity work.

[hhkaos]

Effort assessment

Medium — comparable in size to the two features shipped on 2026-08-12 / 2026-08-13 (per-occurrence "All-day" toggle, per-field disagree warnings on "Edit series"). A couple of focused work sessions, not a rewrite — the batch generation/review/submission pipeline this issue asks to reuse is already built for exactly that:

• recurrence.ts doesn't need to change at all — explicit session dates don't need expansion, only rule-based recurrence does.
• buildRecurringEvents (main.ts) already separates "one date → one event" from "where the dates come from"; it just needs an alternative source of dates.
• The review dialog, the missing-partOf warning/ack gate, and submitRecurringBatch are already agnostic to how the events were generated — none of them need to change.
• The "Link to a series" picker (onOpenSeriesPicker) mentioned in the issue as still needing design has already landed since this issue was filed — that part of the open question is resolved.

What does cost real work: renderRecurrenceRows (ui/form.ts) currently mixes the date/time input block with the frequency <select> — that block needs extracting into a shared helper so the new session-row UI doesn't duplicate it. And this UI layer has no unit tests today (checked test/: nothing covers renderRecurrenceRows/buildRecurringEvents), so verification is manual via the apps/editor:verify skill, not a pnpm test green light.

A design question the issue leaves open, now resolved

While scoping this, we found the natural mapping for "where this control lives and how it interacts with the existing recurrence rows": OTE's partOf.type already has exactly the two values this issue is about — "series" for a recurring event, "multipart" for one event split across sessions (ui/form.ts's field spec: options: ["", "series", "multipart"]). And the recurrence flow already sets a non-destructive default for its own case: opening the series picker from "+ Add recurrence" defaults partOf.type to "series" only if nothing was set yet, never overwriting an existing "multipart" (main.ts, seriesCreateConfirm handler: type: seriesCurrentType || "series").

That precedent generalizes cleanly to the new control:

• "+ Add session" mirrors it in the other direction: if partOf.type is empty, default it to "multipart"; never silently override an existing "series".
• No hard exclusivity between rule-based recurrence rows and explicit session rows. Excluding one control once the other has rows (and needing an "undo" to get it back) would be more confusing than helpful for a genuinely rare edge case. Instead, reuse the existing non-blocking warning pattern already used for the missing-partOf case (onGenerateRecurrenceSeries's warnings list): if both row types have entries when generating, show a soft warning ("mixing rule-based recurrence and individual sessions in the same batch is unusual — check partOf.type matches what you mean") without blocking submission.
• "+ Add session" is always visible next to "+ Add recurrence" in the "Cuándo" section, not gated behind partOf.type already being "multipart" — gating it that way would require setting the type before the control that's supposed to help set it even appears.

Plan

1. Extract the date/start-time/end-time/end-date input block out of renderRow inside renderRecurrenceRows (ui/form.ts) into a shared helper — both row types need it, only the recurrence row also needs the frequency <select>.
2. New SessionRowInput type next to RecurrenceSeriesInput (ui/form.ts): same shape, no rule.
3. New renderSessionRows(...), structurally parallel to renderRecurrenceRows (self-contained subtree, list/addButton/rows array/getSessions()), no frequency dropdown, no expandRecurrenceDates — each row directly is one occurrence. First row added with partOf.type empty proposes "multipart" (non-destructive, mirrors the existing "series" default).
4. New buildSessionEvents(sessions) in main.ts next to buildRecurringEvents — one event per row, no date expansion.
5. Merge both sources inside onGenerateRecurrenceSeries: same review dialog, same missing-partOf ack, plus the new non-blocking mixed-rows warning. submitRecurringBatch needs no changes.
6. Wire the new control into renderForm, next to the existing recurrence rows.
7. i18n: a handful of new keys ("+ Add session" label, mixed-rows warning text); date/time labels are inherited from the shared helper (already translated).
8. CHANGELOG.md entry (required by repo convention for any user-facing change).
9. Manual verification via the apps/editor:verify skill (no unit-test coverage exists for this UI layer today); a unit test in test/recurrence.test.ts only if some new pure function (e.g. date validation/dedup) gets added.

No implementation started yet — recording this to resume later.