[Feature] Persistence behavior keys — breakers, recovery limits, bounded stash

[pathosDev]

Use case

Journal/snapshot failures currently propagate raw (no breaker), unbounded concurrent recoveries can stampede after a node restart, the recovery/persist stash is unbounded, and at-least-once redelivery has no tuning. These are cross-plugin behaviors of the persistence layer itself.

Proposed keys

actor-ts.persistence {
  max-concurrent-recoveries = 50
  recovery-event-timeout = 30s
  stash-capacity = 4096            # commands stashed during recovery/persist
  stash-overflow-strategy = fail   # fail | drop
  journal-breaker  { max-failures = 10, call-timeout = 10s, reset-timeout = 30s }
  snapshot-breaker { max-failures = 5,  call-timeout = 20s, reset-timeout = 60s }
  snapshot-is-optional = off       # recover from events when snapshot load fails
  at-least-once-delivery { redeliver-interval = 5s, redelivery-burst-limit = 10000,
                           max-unconfirmed-messages = 100000 }
  envelope.compression = off       # algorithm + threshold for stored payloads
}

Surveys: a replay filter repairing stale-writer events; a publish-events fast path that feeds live projections without polling.

Acceptance

• A journal outage trips the breaker (fast-fails instead of piling up); recovery concurrency is capped observably.
• Keys ship wired — tests/unit/config/NoDeadConfigKeys.test.ts rejects a key nothing reads.

Related: #628, #736

Part of the reference.conf expansion batch — tracked in #887.

[pathosDev]

Re-derived independently in the production-readiness review tracked in #913, which folded a journal-timeout finding into this issue.

Concrete shape of what the journal-breaker { call-timeout } key would fix, for the acceptance criteria: await this._journal.append(...) (src/persistence/PersistentActor.ts:280) is unbounded today. A backend that accepts the connection and then stalls leaves _persisting = true, so every incoming command is stashed — silently, up to the hardcoded 1024 (src/internal/ActorCell.ts:71, no option, filed as #924) — and then throws StashOverflowError from inside the user's handler. Default supervision turns that into a restart whose cause is 1024 messages away from the stall.

So the failure mode without the timeout is not "slow persistence", it is "a supervision restart that names the wrong thing". There is also no journal latency histogram and no failure counter, so nothing observable moves during the stall — and "journal unavailable" has no section in docs/.../operations/troubleshooting.mdx.