docs(task_history): the acceleration refresh task is acceleration_refresh Eighteen deployment guides (and their 2.0.x-2.3.x snapshots) told readers to correlate object reads and accelerator spans with a task named accelerated_table_refresh. No release has ever recorded that name: the refresh span is declared as "acceleration_refresh" in the accelerated-table refresh task, and the task column is the span name unless a task_override label is present. The name a reader pastes into a task_history query has to match exactly, so a fabricated one returns no rows. cli/reference/trace.md already carried the correct name on these same snapshots.

docs(duckdb): on_full_refresh shipped in v2.1.2 — propagate to version-2.1.x v2.1.2 backported 'on_full_refresh: replace_file' (spiceai#12135) and 'checkpoint_file' (spiceai#12139), and moved 'PRAGMA enable_checkpoint_on_shutdown' from connection setup to instance setup. docs #2004 documented all of this in vNext only, so the 2.1.x snapshot omits a parameter the released runtime accepts. Verified at tag v2.1.2: - ParameterSpec::runtime("on_full_refresh") with the three values and the reuse_file default (crates/runtime/src/dataaccelerator/duckdb.rs) - memory-mode rejection and the refresh_mode: snapshot conflict - with_instance_setup_query("PRAGMA enable_checkpoint_on_shutdown") - the CHECKPOINT -> FORCE CHECKPOINT escalation in datafusion-table-providers rev 1b83cbf (identical rev on v2.1.2 and trunk) Excludes the trunk-only DuckDB changes (coordinated memory budget spiceai#11985, partitioning removal spiceai#11808) and the vNext-only Cayenne 10 GB recommendation.