Rethink OffloadKey variants and task trackability API

[AndreyErmilov]

Current Design

CoreOffloadKey has three variants:

Variant	Fields	Purpose
Keyed	cache_key, kind	Deduplication by cache key
Explicit	kind, id	Named task with caller-provided ID
Auto	kind	Fire-and-forget, ID assigned internally

OffloadManager exposes lookup methods: cancel(&key), is_in_flight(&key).

Problems Identified

1. Explicit exists only as an implementation detail of Auto

Auto keys lack an id field, so they shouldn't be stored in the DashMap directly. The register() method converts every Auto key to Explicit with an auto-assigned ID before insertion. This makes Explicit an internal representation, not a meaningful user-facing variant.

No production code uses Explicit keys directly — it only appears as the conversion target for Auto.

2. cancel() / is_in_flight() are unusable for Auto and Explicit keys

• Auto: The caller never receives the generated ID, so they have no key to pass to cancel() or is_in_flight().
• Explicit: The caller would need to remember the exact kind + id pair, but since IDs are typically auto-generated, this is impractical.
• Keyed: The only variant where lookup actually works — the caller knows the cache key.

These methods are pub but have zero call sites in production code — only in tests.

3. Silent handle overwriting on key collision

When register() is called with a key that already exists in the map (and dedup doesn't apply), DashMap::insert() silently overwrites the old OffloadHandle. The old task continues running as a detached tokio task but becomes untrackable:

• cancel() only reaches the new task
• active_task_count() undercounts
• cleanup_finished() can never remove the orphaned entry
• wait_all() doesn't wait for the orphaned task

This affects Keyed keys with dedup disabled and Explicit keys with reused IDs.