Adds two scenarios to crates/didbot/tests/scenarios/relay.rs. A spec-following subscribeRepos consumer reads the stream live while didbot-pds gets SIGTERM with a write still in flight, then resumes from its cursor on the next process over the same data. One scenario runs under the default announce (on first write), the other under on-create.
Before the deploy, one account writes and another only exists. After it, the quiet account writes for the first time, and a new account is created and writes. Each run asserts several things. No frame carries an account and rev an earlier frame did. Each account gets exactly one #account, and it comes before its first #commit. The repository the consumer held before the deploy is never read whole again. Every write reaches the consumer, and it ends holding exactly what getRepo serves. The consumer now records repeated frames (repeated) for this.
Checked by breaking the code and running both scenarios against it. When a restart ignored the sequence floor and numbered from 1 again, both failed with FutureCursor. When the announced position was never recorded, both failed. Under the default mode the account was announced again, and the consumer re-read a repository it already held. Under on-create the account got two #account frames. The two scenarios add about 10 s on top of the shared binary build.
🤖 Generated with Claude Code