Report the log id a write landed at

[bjmeetsfo]

A block carried in the WAL is addressed by the byte offset of its record, so a write has to learn that offset. The append already computed it and threw it away.

This is the last prerequisite for block-in-WAL: with it, a write knows where its own record landed and can address a block by it.

What it adds

append_with_sync_reporting returns the record and its log id — the record's position in the log's whole history, which stays valid across a reclaim. append_with_sync becomes a thin wrapper that drops the id, so every existing caller is unchanged.

The cached base, and why

Turning a physical offset into a log id needs the reclaim base. Reading it from disk on every append would put a file read on the write path, so it is cached per shard alongside the other per-shard append state: filled on first use, refreshed by reclaim — the only thing that moves it.

That cache is the part worth reviewing. A stale base would report ids wrong by exactly the reclaimed prefix, and those ids would still resolve — to the wrong record. That is the silent failure this whole scheme exists to prevent, so log_ids_reported_after_a_reclaim_account_for_the_base appends after a reclaim and reads the record back by its reported id.

Testing

24 WAL tests pass. New coverage:

• an append reports the log id its record landed at, and each id reads back as that record
• a reported log id still names its record after a reclaim moved it; ids that fail to resolve are only ever ones below the base
• ids reported after a reclaim account for the base

Full-suite attribution

848 passed / 10 failed. One name fails here that is not in my last baseline — raft::tests::part4::raft_replication_deadline_is_configurable_and_bounds_propose — which was already a known flake on pristine main earlier in this series. Worth noting the baseline is older than current main (which gained ~90 tests from #62–#67), so that diff is indicative rather than conclusive; the test is being re-checked in isolation.

Where this leaves block-in-WAL

Merged so far: record types and framing, CRC32C, storage descriptors, the block-retention floor, offset-stable log ids, streaming reclaim. With this, the remaining work is two pieces:

1. carry the block bytes in the WAL record and set the address to the log id;
2. resolve a WAL-resident address on read.

The obstacle for (1) is ordering: execute_on_shard mints addresses before the WAL append happens, across 12 call sites. The bounded route is async_storage mode, which already writes no block at all — the value's only durable copy is its WAL record, held at a synthetic counter address. Replacing that counter with the log id makes it addressable, and fixes the documented hole where an acked write reads back as missing if it is evicted before a dump.