Add growth curve rules to the building block economy

Diagnose that player output equals building count, so the growth
curve must be shaped by the block and space economy: escalating
expansion costs (formula of expansions purchased) as the long-run
curve, a designed doubling time for the block feedback loop, and an
explicit rule that growth is limited by economy, never by
construction waiting. Note the HQ intake ceiling and add the
condensed-building-block idea to future work, plus an action item
for the expansion cost formula.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DyCu8vwChKMbLJQ3xosYEN

docs/progression_design.md

@@ -230,9 +230,37 @@ supporting different fleet doctrines feel structurally different to build.
 - **Rule:** the starting stock suffices for a minimal block loop plus the
   first shipyard — with a little slack for beginner mistakes, but not
   enough to skip the loop entirely.
-- **Rule:** asteroid expansions compete with buildings for the same
-  currency. Expansion pricing makes "more space" a real alternative to
-  "more stuff", not an afterthought.
+- **Rule: the growth curve lives here.** A saturated building produces
+  exactly 1 threat/s, so the player's output curve *is* their
+  building-count curve — shaping growth over a run means shaping the
+  block and space economy, there is nowhere else it can live. Intended
+  shape: exponential bootstrap (block-limited) → ramp
+  (expansion-limited) → asymptotic squeeze as expansion costs outrun
+  income, racing the enemy threat rate throughout.
+- **Rule: escalating expansion costs.** Expansion cost is a formula of
+  the number of expansions already purchased, rising steeply enough that
+  expansions eventually outrun any block income. The starting asteroid
+  is deliberately small — filled within the first boss cycle or two, so
+  the early exponential burst is a satisfying ramp, not a balance hole —
+  and from then on the output curve is the expansion curve. Blocks keep
+  a meaningful sink for the entire run, and "grow vs. army" stays a live
+  decision at every moment.
+- **Rule: designed doubling time.** Block production is a positive
+  feedback loop (blocks buy assemblers, assemblers make blocks); its
+  time constant is a designed quantity, never an accident of quantity
+  choice. The block chain's depth and the per-building costs are tuned
+  against a stated target of the form: "a factory spending X% of its
+  capacity on blocks doubles in ~T minutes."
+- **Rule: growth is limited by economy, never by waiting.** Construction
+  times stay short; the serial build queue must not be used as a growth
+  brake. Waiting for placed buildings to become operational — especially
+  at the start of a run — is frustration, not gameplay. All growth
+  limiting comes from block income and expansion pricing.
+- Note: block income has a structural ceiling — blocks enter the stock
+  through the HQ's single belt port, so income is capped at belt
+  throughput regardless of assembler count. Per-building costs should be
+  high enough that this cap can bind late-game (see the condensed-block
+  idea under Open tasks).
 
 ## Numeric guardrails
 
@@ -260,6 +288,11 @@ Constraints that every recipe must respect, independent of tuning:
   `unlock_at_station_level` ladder, real threat costs and
   `default_modules`, reprocessing weights, and the threat-rate formulas
   according to the rules above.
+- **Condensed building blocks** — a drop-unlockable shortcut-style
+  recipe that packs several blocks' worth of value into one belt item,
+  relieving the HQ intake ceiling (see Building block economy) as a
+  late-game reward. The ceiling is the puzzle, the drop is the fix —
+  same philosophy as shortcut recipes.
 - **Mk2 upgrade recipes** — the deferred design for per-item progression,
   to revisit once the config has stabilized. A duplicate-style drop
   unlocks a distinct `*_mk2` item whose recipe consumes the Mk1 item plus
@@ -292,3 +325,8 @@ in `requirements.md` and the git history). Still open:
    recipe schematic pool eligibility in REQ-DEF-SCHEMATIC-DROP: in
    addition to the existing station-level and output-item checks, all of
    the recipe's input item types must be implicitly unlocked as well.
+4. **Expansion cost formula.** Replace the flat
+   `world.toml [expansion].cost_building_blocks` with a formula of the
+   number of expansions already purchased (x = expansions bought so
+   far), so expansion costs can escalate per the block economy rules.
+   Update REQ-EXP-COST and wherever the UI displays the expansion cost.