stella-store: project behavioural tendencies per turn (turn_tendencies) so they aggregate beyond one execution

[macanderson]

Problem

Behavioural events — retry, retries_exhausted, loop_detected (kind + aborted), budget_denied, compaction (before/after tokens), policy_decision (kind), speculation_discarded, steered, provider_fallback, usage_incomplete — live only in the events journal. The observatory's /api/execution-tendencies (added with the Sessions tab, see crates/stella-observatory/src/sessions.rs::execution_tendencies) folds them per execution, which is the sanctioned per-execution events read. But session-, workspace-, and org-level tendency trends are impossible without a projection: the observatory's journal rule ('a cross-execution view needs a projection, not a wider WHERE', crates/stella-observatory/src/db.rs::execution_journal docs) forbids the query that would compute them.

Build

A turn_tendencies table in crates/stella-store/src/ddl.rs (one row per execution: retries, retries_exhausted, loop_detections, loop_aborts, stagnations, budget_denials, compactions, tokens_reclaimed, policy_blocked, secrets_detected, speculation_discarded, steered, provider_fallbacks, usage_incomplete), written at turn end from record_execution_end (crates/stella-cli/src/agent/persistence.rs, beside finalize_execution_reflection) — or live-projected like tool_calls v18. crates/stella-serve/src/observe/tally.rs::TallyFold already computes exactly this vector in memory; reuse its fold rather than writing a second one. Add the table to prune.rs::DEPENDENT_TABLES (its test enforces coverage).

Then the observatory can aggregate per session (JOIN executions ON session_id) and per day, and /api/execution-tendencies can read the projection with the journal fold as fallback for old stores.

Verify

Witness: seed an execution whose journal carries a retry + a loop_detected via Store::record_event, finish the turn, assert the turn_tendencies row exists with those counts — fails on main (no table). Observatory side: extend crates/stella-observatory/tests/schema_conformance.rs.

Constraints

• No I/O in stella-core (invariant 2); the fold is pure, the write goes through stella-store.
• Migration bumps migrations::SCHEMA_VERSION; the observatory must keep degrading on stores without the table (is_missing_schema).

Refs #1461, #1476.

[macanderson]

Triage 2026-08-06: P2 — additive telemetry feature (per-turn behavioural tendency projection), no defect. Plan: as specced in the body; the store schema addition should follow the migrations pattern in crates/stella-store/src/migrations.rs and the content-free allowlist in content_free.rs must be updated in the same PR if any new hub column ships (invariant 3 makes the gate fail otherwise — that is by design). Next step: schema sketch + the aggregation query shape, then the write path from the reflection miner.