Make aggregate state graphs content-driven, not compiled Rust

Six hand-maintained copies of the bucket->aggregate-type table
(4 per-type State enums, content::aggregate_type_for_bucket +
is_valid_transition_target, answers.rs's two dispatch matches,
backfill_events.rs's own migration table) collapse into one:
questions/aggregates.yaml, loaded and hot-swapped in AppState.aggregates
the same way AppState.questions already is. aggregates/mod.rs's
replay/create/transition now run off a runtime-loaded AggregateSchema
instead of a compile-time AggregateKind trait impl per type - the
CAS/JetStream mechanics underneath are unchanged. A new aggregate type
is now a content-only change, no portal deploy required.

backfill_events.rs is deleted outright rather than ported - its
migration job was already done and production data here is minimal
and expendable (the EVENTS stream gets purged by hand post-deploy).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

src/server/mod.rs

@@ -22,6 +22,12 @@ pub struct AppState {
     /// a lock, just an atomic pointer load, so a reload never blocks or
     /// is blocked by an in-flight request.
     pub questions: Arc<ArcSwap<HashMap<String, Question>>>,
+    /// Every bucket's event-sourced state graph, loaded from
+    /// `aggregates.yaml` (see `content::load_aggregates_from_gitea`) and
+    /// hot-swapped alongside `questions` on the same reload. A bucket
+    /// with no entry here isn't event-sourced - plain KV mutate-in-place
+    /// still works (see `answers.rs`).
+    pub aggregates: Arc<ArcSwap<HashMap<String, crate::aggregates::AggregateSchema>>>,
     /// `scheme://host` of the Gitea instance content is loaded from
     /// (see `content::gitea_api_base`) - kept alongside `questions`
     /// rather than re-derived per call, since `resolve_gitea_repo` needs