fix(crews): J5 stream daemons start from the event store's high-water mark

[bryantderosier]

Problem

Three J5 background workers took their event-stream start point from SELECT MAX(sequence) FROM orchestration_v2_events. Nothing has written that table since the upstream sync, because V2 events now live in orchestration_events, so the query returns 0 and every boot replays the whole event history (#349). On j5/main that already lets the Captain archive cascade replay an old Captain archive on restart and retire live Crews while their Captain stays live. #315 would widen it to replayed unarchive, settle, and unsettle events, so this has to land before #315.

What I changed

• New J5 helper apps/server/src/j5/a2a/eventStoreHighWater.ts → readEventStoreHighWater: reads EventSinkV2.latestSequence(). On failure it logs and retries with capped backoff (250 ms up to 30 s), and never falls back to 0.
• CrewSeatFinishNotifier.ts → runDaemon and CrewLaunchReporter.ts → runDaemon: start from that helper. The raw queries are gone, and so is the launch reporter's unused SqlClient.
• SilenceDetector.ts → initializeCursor: seeds its durable cursor from latestSequence(). A failed read fails the seed, and the lifecycle daemon already retries that step.
• runtimeLayer.ts: the J5 runtime layers get OrchestrationV2EventSinkLayerLive. It's the same layer object the orchestration runtime uses, so there's one sink instance.
• A separate commit fixes a misleading comment on fix(crews): Crew notices report only what the platform measured #292's daemon-mode alert test (Jackson's optional nit there; fix(crews): Crew notices report only what the platform measured #292 had already merged). That test is an end-to-end smoke check, and the wake-count test is the regression test.

Why this shape

• EventSinkV2 rather than the lower-level store: ThreadManagementService.streamStoredEventsFrom streams from the sink, so the start point and the stream share one sequence space. It's also what QueuedRunWatchdog already uses.
• Retry instead of starting at 0: starting at 0 is the bug. Giving up would stop Crew reactions until the next restart.

Invariants

• No J5 daemon opens its stream, or runs its boot reconcile, before it has a real start point.
• The start point and the stream read the same service.

Surfaces

Surface	Decision
Entry points	Unaffected.
Clients	Unaffected.
Providers	Unaffected.
Contracts	Unaffected.
Reverse states	Not applicable.
Connection modes	Unaffected.
Upstream files / FORK.md	None; only J5-owned files. FORK.md's "resumes from its high-water mark" is accurate again.
Docs	Unaffected.

Out of scope

• An install whose silence cursor was already seeded at 0 by the bug has already caught up on that one replay; this only changes how new cursors are seeded.

Upgrade and data

None. The next boot after this lands starts each stream at the current high-water mark.

Verification

• apps/server, apps/web, and packages/contracts typecheck (exit 0).
• vp test run apps/server/src/j5: 1,061 passed, 1 skipped. runtimeLayer.test.ts: 47 passed.
• New tests, all signal-based with no sleeps:
  • The finish notifier's and the launch reporter's streams open after the mocked latest sequence.
  • A failed first read opens no stream until the retry succeeds.
  • SilenceDetector seeds its cursor from latestSequence, including after a failed read.
  • With the three source files reverted, all five fail.
• Lint and format are clean.

Review focus

• The retry-until-success choice in readEventStoreHighWater, and whether a daemon should ever give up.

Closes #349

Claude Opus 5.5 via Claude Code in J5 Code

🤖 Generated with Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Repository: Jacksondr5/j5code/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 97217cfb-88ea-46f5-a536-1e61ab1f74eb

---

_{Comment @coderabbitai help to get the list of available commands.}

[Jacksondr5]

Posted by an AI agent on Jackson's behalf.

Approved. This is the right fix for #349. It reads the start point from the event store service itself, so the start point and the stream share one sequence space without repeating a table name. The wiring stays in J5-owned runtimeLayer.ts. 41 tests pass across the five affected files, and CI is green.

On your review-focus question: retrying forever with capped backoff is fine to keep. It's small, and it never falls back to 0, which is the actual bug. By the "repair beats edge-case machinery" principle, failing loudly would also have been acceptable, since a store that can't answer its latest sequence is broken anyway. Not a blocker.

This supersedes #353, which duplicated this fix and is now closed. Merge this before #315.