A repeat should hold as many instances as the reader has, up to max

Goal

When a worksheet says "divide your life into 5–8 chapters", the reader decides where in that
range they land. Some people have eight phases they want to name; some have five. Today the
workbook silently gives everyone five, which quietly changes the question it asked.

Current Behavior

build/questions.ts renders question.min slots (lines 472 and 521) — min does two jobs,
and src/questions/types.ts says so: "Fewest instances the worksheet asks for, and how many
slots the sheet prints". max is documented as "Most the reader may add once #24 can add
them. Not printed." Nothing can add them: ADR 0013 · C6 states plainly "This is still not the
add-another control."

Three groups have a range, so this is not hypothetical:

Eleven instances a reader is invited to have and cannot.

Worse than absence: an instance order longer than the rendered slot count is accepted in
silence. ADR 0013 · Q2 records it — "an order LONGER than the slot count is accepted without
comment, and the answers under its extra instances simply never appear." So a reader who gets
eight chapters into the store by any route loses three of them without being told, which is
the failure mode ADR 0008 treats as the worst available to this application.

Some groundwork already exists. The repeat container carries data-min and data-max
(build/questions.ts:493), so the markup already states the range. ADR 0013 chose mint-on-
first-write precisely so the control could arrive later without a migration — "It makes one
possible without a migration, which is the point of doing it before answers exist rather than
after."

Proposed Solution

1. An add-another control, up to max, appending an instance and its identifier through
   keys.ts (newInstanceId, writeOrder) — the only path into the format, per 0013.
2. Render every instance the store holds, not min of them, so an order longer than the
   printed slot count shows rather than hides. That is the half of 0013 · Q2 that is still
   silent.
3. Decide the shrinking half of Q2 too, or record explicitly that it is still open: what
   happens to answers under instances when min falls, or when a reader wants one gone. Note
   there is currently no way to remove an instance either, and "remove" is the more dangerous
   of the two — it deletes writing.
4. Printing (ADR 0010) needs an answer: a blank worksheet prints min ruled slots, but a
   completed one should presumably print what the reader actually wrote.

Acceptance Criteria

1. A reader can add instances to a repeat up to its max, and the control disappears or
   refuses at the ceiling rather than failing silently.
2. Answers under an added instance save and reload like any other.
3. An instance order longer than the rendered slot count displays every instance it names —
   asserted directly, since it is the silent-loss path 0013 · Q2 describes.
4. The order written is one keys.ts would itself have written; identifiers come from
   newInstanceId and nothing else.
5. Negative case: at max, no further instance can be added by any route the interface
   offers.
6. A group with no answers still renders min slots, so the blank worksheet is unchanged.
7. Whatever is decided about removal and about printing is recorded, including "not yet" —
   0013 · Q2 has been open across three pull requests and deserves an answer or an explicit
   deferral rather than a third silence.

Why this is recorded separately

It surfaced while building the agent bridge (#67), where the prompt generator had to ask an
assistant for five chapters rather than the "5–8" the worksheet asks for, precisely to
avoid producing answers nothing could display. ADR 0015 bounds an import at the rendered slot
count for the same reason. Both are workarounds for this gap rather than the shape either
would choose.

When this lands, three things can be revisited: the prompt can ask for the range (0015 · C8),
the importer's ceiling becomes max rather than the slot count, and 0015's bound can be
relaxed to the thing it was standing in for.