Growing a campaign's app bundle mid-campaign — deferred by design

Decided during the study-first implementation review (2026-08-21): a campaign's app bundle is **fixed at `campaign init`** in the study-first implementation. Adding an app to a running campaign is deliberately unsupported.

The preferred pattern when you want another app is to **create a new campaign** — a campaign is a config epoch, and a new bundle is a new epoch. That keeps `add-dataset` simple (re-selecting an already-selected dataset just refuses) and avoids the row-materialization machinery a growing bundle needs (which cells exist becomes partly derived state, the reconciler has to fill missing cells per tick, and the intuitive UX for it is unclear — re-running `add-dataset` per dataset after a bundle edit certainly isn't it).

If a real need to extend a live campaign shows up, reopen the design here. The per-cell add machinery that would seed it existed briefly on the `study-first-add-dataset` branch (see its history) before being simplified out.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

This issue is explicitly deferred and names no implementation files or tests. Start by reviewing the study-first implementation and the history of the study-first-add-dataset branch; only reopen the design if a real need to extend a live campaign appears, then define the bundle and row-materialization behavior before implementation.

Written by the indexing model from the issue text.