Function write_pid_values 

pub async fn write_pid_values(
    pool: &Pool<Sqlite>,
    run_id: i64,
    driver: &dyn Driver,
    p_tag: &str,
    i_tag: &str,
    d_tag: &str,
    response_level: ResponseLevel,
    target: WriteReadback,
    kind: WriteKind,
    allow_uncertain: bool,
) -> Result<PidWriteOutcome, Error>

Pre-reads the existing Proportional/Integral/Derivative values, writes and verifies target (Proportional then Integral then Derivative, stopping at the first failure), rolls back to the pre-read values on partial failure (only for kind = WriteKind::Write -- [WriteKind::Revert] never does, so a revert can't chase its own failure with a nested rollback; see [WriteKind]'s own doc comment), and records exactly one [TuneWriteRow`] audit row for the attempt, success or not.

The one implementation of “pre-read, write, verify, roll back, audit” in the whole workspace, shared by three callers: maybe_write_back’s in-run write-back, crate::history::revert_run, and bhtune-server’s post-hoc POST /api/runs/{id}/write/ .../revert – pub (not pub(crate)) specifically so that third, different-crate caller can reach it. bhtune-server calls only this function, not the lower-level read_previous_pid_values/write_and_verify_pid_value helpers this builds on – those stay pub(crate), since adapters need only the complete audited sequence.

target is the caller-selected P/I/D values to write: freshly calculated parameters for a WriteKind::Write, or a past write’s recorded previous values for a WriteKind::Revert. Never propagates a driver/database error via ? for an operational failure – a pre-read failure, a rejected write, a failed confirmation readback, or a failed rollback all still produce their audit row and return PidWriteOutcome::Failed; the Err case is reserved for the one thing that really is exceptional here, TuneWriteRow::insert itself failing.