chore(deps)!: bump es-entity to 0.13.0, job to 0.15.2, obix to 0.12.1

[bodymindarts]

Summary

• Bumps es-entity 0.12.21 → 0.13.0, job 0.14.0 → 0.15.2, obix 0.11.0 → 0.12.1 — all breaking 0.x bumps.
• es-entity 0.13.0: PaginatedQueryRet gates construction behind ::new(entities, has_next_page, end_cursor, requested_size) and the entities field behind .entities()/.into_parts() (chore(deps): bump serde from 1.0.208 to 1.0.210 #229). Every repo that hand-built the struct now calls ::new(...) with the query's first as requested_size; callers that read .entities move to .entities() or .into_parts().
• obix 0.12.0: replaces the commit-ordered envelope with a lane typed into the delivery itself (docs: add plugin-google-gtag and analytics to website #156). SingletonSubscriber::handle_persistent now takes &EventDelivery<P, L> instead of &Arc<PersistentOutboxEvent<P>> (retention via event.inner().clone()), Subscription::await_sequence → await_position, and SubscriptionError::CaughtUpTimeout/SubscriptionStreamStatus report the dynamic StreamPosition instead of a lane-typed sequence. cala only runs the default insert lane, so EcRollupStatus and LedgerError::EcCaughtUpTimeout are updated to match with no behavior change.
• obix 0.12.0 also replaces the commit-log partition tables with a sparse persistent_outbox_commit_checkpoints table, and job 0.15.0 adds job_waiters plus job_executions.woken_at for wake-on-completion. Both migrations are updated in place — regenerated verbatim from the upstream templates (byte-for-byte round-trip verified after stripping the cala_ prefix) — since nothing is live on this schema yet.
• job 0.15.2 / obix 0.12.1 are trailing patch releases that only strip comments from their migration templates; the cala-prefixed copies here are updated to match, with no schema change.
• .sqlx query cache regenerated against the new schema.

Test plan

• SQLX_OFFLINE=true cargo build --locked --workspace --all-targets --all-features
• SQLX_OFFLINE=true cargo clippy --workspace --all-targets --all-features (clean)
• cargo nextest run --workspace --all-features against a fresh local Postgres migrated from these migration files — 219/219 passed
• cargo run -p cala-ledger --bin event-schemas --features json-schema — no schema drift
• cargo doc --no-deps — no new warnings

🤖 Generated with Claude Code

---

Note

High Risk
Rewrites job and persistent-outbox migrations and job scheduling SQL while changing pagination and outbox delivery APIs—high impact on background jobs, EC rollup lag/wait semantics, and any consumer of paginated list types.

Overview
Breaking dependency upgrade for es-entity 0.13.0, job 0.15.2, and obix 0.12.1, with matching Cargo.lock and regenerated cala-ledger/.sqlx offline query metadata.

es-entity: Pagination results are no longer built with struct literals. Repos construct PaginatedQueryRet::new(..., query.first) and callers read pages via .entities(), .into_parts(), or updated pagination continuation patterns in tests.

obix: Persistent delivery moves to EventDelivery in handle_persistent (EC rollup clones via event.inner()). Subscription waiting uses await_position and StreamPosition in errors/status instead of lane-typed sequences. The outbox commit path drops partitioned cala_persistent_outbox_commit_log + state tables for sparse cala_persistent_outbox_commit_checkpoints (migrations rewritten in place).

job: Schema adds job_waiters, job_executions.woken_at, and updated queue promote/reschedule/retry SQL (wake-on-completion semantics). Job setup migration is trimmed/regenerated to match upstream templates.

Ledger surface: EcRollupStatus is built from explicit checkpoint() / frontier(); LedgerError::EcCaughtUpTimeout carries StreamPosition.

^{Reviewed by Cursor Bugbot for commit 8f35899. Bugbot is set up for automated code reviews on this repo. Configure here.}

[bodymindarts]

ugly - I thought into_parts() was internal only... why is it pub?

[vindard]

I think this is an anti-pattern. I left into_parts because I'm thinking want both entities and the next query if we need the entities. Having entities alone is a signal that we are ignoring future pages. The intention is to fetch let (entities, next) = query.into_parts() or let next = query.into_next_query() but never let entities = query.into_entities() and never this tuple destructuring style, since this might signal a bug if we're ignoring next pages?

[bodymindarts]

okay - can you PR here to show what should be idiomatic?

[bodymindarts]

Ugly - why does C now carry this constraint? We shouldn't mandate that constraint on library users.

[github-actions]

📊 Performance Report

Commit: 8f35899
Updated: 2026-09-18 08:37:49 UTC

Cala Performance Benchmark Results (non-representative)

Criterion Benchmark Results (single-threaded)

Benchmark	Time per Run	Throughput	% vs Baseline
post_simple_transaction	2.923ms	342 tx/s	0 (baseline)
post_multi_layer_transaction	4.006ms	249 tx/s	-37.0%
post_simple_transaction_with_effective_balances	6.234ms	160 tx/s	-113.0%
post_simple_transaction_with_skipped_velocity	2.466ms	405 tx/s	+15.0%
post_simple_transaction_with_velocity	3.256ms	307 tx/s	-11.0%
post_simple_transaction_with_hit_velocity	1.529ms	653 tx/s	+47.0%
post_simple_transaction_with_one_account_set	3.100ms	322 tx/s	-6.0%
post_simple_transaction_with_five_account_sets	3.652ms	273 tx/s	-24.0%
post_simple_transaction_with_ec_account_set	3.120ms	320 tx/s	-6.0%

Load Testing Results (parallel-execution)

Scenario	tx/s
1 parallel	223.82
2 parallel	381.04
5 parallel	450.14
10 parallel	455.43
20 parallel	495.72
2 contention	168.18
5 contention	241.41
2 acct_sets	157.27
5 acct_sets	195.86

---

Note: Performance results may vary based on system resources and database state.

Last updated by commit 8f35899