LEP: Add storage interface for get/put of foreign keys

[mjansson]

Motivation

Callers that address content by a key belonging to some other system -- an asset id, a build id, a database primary key -- need both keyspaces for every access, and the two are serially dependent: a read is mutable_load then get, a write is put then mutable_store, and the second cannot start until the first answers. The latency is two round trips regardless of how much work is queued behind it, which is what decides whether Lore is usable as a cache for foreign-keyed data.

Summary

Add get_resolved and put_resolved, which resolve a key and act on the content it names within one request. Keys live under KeyType::Resolve, so the type is implied rather than sent. Both operations are available over QUIC and gRPC with the same semantics, and through lore_storage_get_resolved and lore_storage_put_resolved in the C API.

A read resolves local-first and falls back to the remote on a miss, caching the mapping it learns; a locally cached mapping that names content this store does not hold defers to the remote rather than reporting a miss. The root fragment arrives with the resolution, so there is no local probe for it -- that is the round trip being saved -- but it is decompressed and verified against the resolved hash exactly as load_fragment does, so a server that resolves a key to the wrong content is caught rather than trusted. Leaves still go through load_fragment, and so are still served from and written back to the local store. Reads take the same streaming option an ordinary read does, delivering one event per leaf fragment so peak memory follows the fragment size rather than the content size.

A write stores the content before publishing the key, so a key never names content the store does not hold. Content that fits one fragment publishes from inside the ordinary write pipeline: the upload it was going to perform anyway becomes put_resolved rather than put, so content and mapping travel together and the terminal local write is the only local write, already carrying the durable flag and the local_cache_priority retention decision. A publishing write never joins the in-flight rendezvous -- deduping onto another writer's upload would mean no upload of our own, and the key rides on the upload, so it would silently never ship. Content already durable uploads nothing, so there is no command for its key to ride on and the mapping follows as a mutable_store instead; still one round trip, without re-sending a payload the server holds.

A fragment tree cannot fuse: its leaves upload first and the key is published only once the whole tree is durable. Writes report where content landed -- local, remote, or both -- as the intersection across every fragment, so a caller can tell content that reached the remote from content that only reached the local store. A remote leg that fails is warned rather than returned: the local write still stands, and the reported placement says so. A publish carrying no content retracts the key.

Publishing is last-writer-wins, deliberately: for the caching this exists for either mapping is valid. Folding in a compare-and-swap is not available, because content must be stored before the key names it and a failed swap would strand what it just stored, worst under exactly the contention that would motivate it.

Auxiliary

Add shared store control to be able to override the machine global config in tests and when running CLI/API commands. Previously tests targeting shared store would behave differently depending on what config the machine had, not isolated to the test.

Tests

Updates the integration test harness to be able to test both QUIC and gRPC transports, and to work without pre-generated certs. Also leverage the new shared store control to ensure tests are run in a controlled environment without interference from system configuration.

[epic-lore-bot]

Imported as Lore CR-363.