Unchecked `commit_count - 1` subtraction in receipt sequence computation rests on an implicit invariant

`rs/cyphr-server/src/routes.rs` computes a receipt's `sequence` field as `t.commit_count - 1` in three places (the tip and push response paths). This is a plain `u64` subtraction with no overflow check.

It's safe today: the storage engine guarantees `commit_count >= 1` whenever a tip exists (a tip implies at least a genesis commit), so the subtraction never wraps in practice. But the safety rests on that invariant holding at every call site indefinitely, with no compiler or runtime signal if a future change to the indexer ever violated it — the subtraction would silently wrap to `u64::MAX` rather than fail loudly.

Worth a `debug_assert!(t.commit_count >= 1)` or a `checked_sub` with an explicit error path if the indexer surface grows or gets refactored, so a future violation of the invariant fails loudly instead of silently wrapping.

Part of the server production-readiness effort tracked in #23. Discovered during the work tracked in #88.

Read rs/cyphr-server/src/routes.rs and inspect the three tip and push response call sites that compute receipt sequence from commit_count. Trace the existing error-handling path before choosing how the commit_count >= 1 invariant should be enforced; done means a violated invariant fails loudly rather than silently producing u64::MAX.

Written by the indexing model from the issue text.