saveLeaderForTerm

Persists leaderId as the node §5.2 established as leader of term, replacing any previously stored record.

Written once per term — on this node's first leader-contact of that term, or on winning it — so the cadence is the same as saveTermAndVotedFor's, not a per-heartbeat cost.

Why it survives a restart: §3.10 leadership transfer authenticates an incoming TimeoutNow against the leader established for the current term, and that check is only as good as the node's memory of it. A node that comes back holding no leader for a term it durably restored cannot tell the real leader's TimeoutNow from any other voter's, and must either accept both or break the honest transfer.

Implementations MUST write term and leaderId as one record: a crash between two separate writes would leave an identity paired with a term it was never established for, which is worse than holding no record at all — the engine's staleness check compares the stored term to its own and would admit the mismatched identity as authoritative. A single row (UPDATE raft_meta SET leader_term=?, leader_id=?) satisfies this; two independent keys do not.

It need not be atomic with saveTerm / saveTermAndVotedFor: the two are written at different moments by construction, and a self-describing record is exactly what removes the need.