Function write_pid_values 

pub async fn write_pid_values(
    pool: &SqlitePool,
    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>

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 (safety-writeback-rollback`, finding 6 of the live-plant safety review).

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, commands::history::revert, and bhtune-server’s post-hoc POST /api/runs/{id}/write/ .../revert (api-post-run-write) – 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 nothing outside bhtune-cli needs the individual pre-read/write-single-value steps, 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.