Add linera_cache::Arc<T> newtype enforcing one-allocation-per-content invariant

[ndr-ds]

Motivation

Follow-up to #6147 (reviewed by @ma2bd). The previous PR pushed Arc deeper through the certificate/block paths but left the door open for callers to bypass the dedup guarantee by constructing a fresh Arc::new(value) and inserting it — the type alone couldn't enforce "this came from the cache".

Proposal

Introduce linera_cache::Arc<T>: a #[repr(transparent)] newtype over std::sync::Arc<T> with no public constructor. The only way to obtain one is through ValueCache::insert, ValueCache::insert_hashed, or ValueCache::get. This makes the dedup invariant structural: if you hold a CacheArc<T>, it provably came from the cache.

API surface:

• into_std(self) -> std::sync::Arc<T> — for crossing trait/network/serde boundaries
• as_std(&self) -> &std::sync::Arc<T> — for read-only boundary crossings
• unwrap_or_clone(this: Self) -> T — mirrors Arc::unwrap_or_clone
• Deref<Target = T>, Clone, From<CacheArc<T>> for std::sync::Arc<T>

Re-exported from linera-storage as pub use linera_cache::Arc (aliased as CacheArc inside consuming crates).

Test Plan

CI — existing tests exercise the cache paths and the type changes are mechanical (boundary conversions via into_std()/as_std()).

Release Plan

• Nothing to do / These changes follow the usual release cycle.

Links

• Push Arc deeper through certificate and block paths #6147 — the PR this follows up on
• reviewer checklist

[ma2bd]

To be clear, this line only matters for unsafe transmute operations, which we don't use, correct?

[ndr-ds]

Good point, let me remove

[ma2bd]

nice

[afck]

(Wouldn't it be easier to keep crate::Arcs in the map, rather than (std) Arcs? Then we wouldn't have to explicitly create crate::Arcs everywhere.)

[afck]

Wouldn't it be safer (i.e. less prone to accidental duplicates) if handle_confirmed_certificate also required a CacheArc?