Add promotion to Dispatch, and measure how repetitive a run is

The mailroom is no longer the whole game. Around turn 50, a player who has
built standing and either Marlene's goodwill or the nerve to ask gets offered
the Dispatch post — and can take it, take it and put Trevor up for the mailroom,
or turn it down, which is a real strategy rather than a mistake and comes back
after a cooldown.

Dispatch is eleven events of its own. The money problem is largely solved up
there and replaced by other people's days depending on yours, including the
mailroom's — which you used to be. Trevor branches on whether you recommended
him: he either runs the mailroom and has opinions about how it used to be run,
or he stays put and starts addressing you by your full title, kindly, in front
of people.

None of this is a promotion mechanic in the engine. It is
`{ path: 'stage', op: 'set', value: 'dispatch' }` on an option, since `stage`
was already how events are filtered. The reserved-write rule now allows it
narrowly — `set` only, and only to a stage that has events, both checked by the
validator, so a typo cannot strand the player in an empty pool. Wages differ by
rank through two upkeep entries gated on `stage`. The hard-times events dropped
their stage entirely: rent is due wherever you work.

The second half of this is the thing the last playtest asked for. A 183-turn
session, and no way to see how much of it was new ground.

`npm run analyze <exported-log.json>` now reports turns against distinct
situations, how often each recurred, which options were most used, which locked
gates players kept meeting, and anything they typed. The retrospective shows the
player-facing version.

It found a regression in this very change on its first run. Dispatch started
with eight events against the mailroom's nineteen, so its two floor events were
46% of every promoted run — one every three turns. Promotion was moving the
player into *thinner* content. Three more events and a weight rebalance took the
top two to 24.5%, and the heaviest recurrence from every ~3 turns to every ~5.
A test now holds that line.

Also corrected: the coverage test was asking whether an archetype ever *took* an
option, which is a property of the bot, not the pack. It had flagged
`rent_bounced.ask_trevor` as dead content when it had been offered, unlocked,
419 times across a sweep and simply never chosen. Options are now checked on
availability; events are still checked on firing.

114 tests. Reasoning in docs/DECISIONS.md §22-24.

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

docs/DECISIONS.md

@@ -261,3 +261,55 @@ well-liked. That last one exists because the "ask a friend for money" options
 sit in a state no single-axis strategy ever reaches. The economy's shape is
 asserted as an ordering between archetypes rather than as absolute figures, so
 tuning does not churn the tests.
+
+## 22. Stage is the one piece of engine state content may write
+
+A promotion is `{ path: 'stage', op: 'set', value: 'dispatch' }` on an option's
+effects. Nothing else about it exists in the engine — `stage` was already how
+events are filtered, and moving the player between stages is a content
+decision, so the reserved-write rule now allows it.
+
+It allows it narrowly. Only `set`, and only to a stage that actually has events;
+both are checked by the validator. A typo cannot strand the player somewhere
+with an empty event pool.
+
+Wages differ by rank through two upkeep entries gated on `stage`, not through
+any notion of rank in the engine. The hard-times events dropped their `stage`
+entirely and so apply everywhere — rent is due wherever you work, and that
+branch has to follow the player up rather than vanishing on promotion.
+
+## 23. What "reachable" means for an option
+
+The coverage test used to ask whether an archetype ever *took* an option. That
+is the wrong question: whether a bot picks something is an artefact of how the
+bot scores, not a property of the pack. `rent_bounced.ask_trevor` was offered
+and unlocked 419 times across a sweep and chosen once, and the test called it
+dead content.
+
+Events are still checked on firing, since the engine draws those. Options are
+checked on *availability*: every option must, at some point, be offered to a
+player unlocked. What they then do with it is theirs.
+
+## 24. Variety is a measured property of the pack
+
+Playtest: a 183-turn session, *"mailroom stayed mostly interesting despite the
+number of repeats… what might be of interest is seeing how many turns are
+played versus how many unique situations."*
+
+So it is now measured, in three places.
+
+`tools/analyze-log.js` reads an exported feedback log and reports turns against
+distinct situations, how often each recurred, which options were most used,
+which locked gates players kept meeting, and anything they typed. The
+retrospective shows the player-facing version of the same thing.
+
+And a test asserts no single event exceeds 25% of a 200-turn run, and that a run
+sees more than 60% of what was reachable in the stages it visited — measured
+against reachable content, since a run that never leaves the mailroom cannot see
+Dispatch and counting that as thin would be measuring career progress instead.
+
+That guardrail exists because the first version of Dispatch failed it badly:
+eight events against the mailroom's nineteen meant its two floor events were 46%
+of every promoted run, one every three turns. Promotion was moving the player
+into *thinner* content. Three more events and a weight rebalance took the top
+two to 24.5%, and the heaviest recurrence from every ~3 turns to every ~5.