Per-instance generation counters make bad cache keys: key#generation repeats after an evict and reload

Pitfall seen while reviewing a design-model cache in an editor or viewer. Each loaded design got an id built as <key>#<generation>. The generation counter lived on the loader instance and started at 1. When the cache evicted a design (LRU, max N) and later recreated it under the same key, the new instance started at generation 1 again. So key#1 came back even though the sources had been edited. A client that keeps cached answers while the id is unchanged then served stale results.

Fix: make the id unique for the whole process. Use a process-wide monotonic serial, or a random nonce per instance, combined with the content fingerprint. Also have clients drop their session state when the server says the design isn't loaded, rather than keeping it.

A related race: a reopen that joins an export or load that's already running inherits that run's result, which was computed from pre-change inputs. Give each open a sequence number, and drop or rerun any result from a superseded sequence.

Test idea: build two real loader instances, load different sources in each, and check that a request stamped with the first instance's id is refused by the second.