[CELEBORN-2489] Fix unknown worker lookup in shuffle data loss detection

[zaynt4606]

What changes were proposed in this pull request?

Use allocatedWorkers.containsKey(workerId.toUniqueId) when checking whether an unknown worker belongs to a shuffle.

Add focused tests for an allocated unknown worker, an unrelated unknown worker, disabled detection, enabled replication, a different failure status, and a shuffle without allocated workers.

JIRA: https://issues.apache.org/jira/browse/CELEBORN-2489

Why are the changes needed?

allocatedWorkers is a ConcurrentHashMap[String, ShufflePartitionLocationInfo]. Its legacy contains method checks values, while the lookup argument is a WorkerInfo. The condition therefore remains false even when the lost worker is allocated to the shuffle.

With celeborn.client.shuffleDataLostOnUnknownWorker.enabled=true and replication disabled, the client should report shuffle data loss as soon as an allocated worker becomes WORKER_UNKNOWN. The current check misses this and waits for a later failure path. This fix restores the existing early failure behavior and preserves the configuration and replication guards.

Does this PR resolve a correctness bug?

• Yes

Does this PR introduce any user-facing change?

• Yes

Restores the configured early failure behavior for a lost allocated worker.

How was this patch tested?

• Before the fix, the new suite runs six tests: the allocated unknown-worker case fails and the other five pass.
• After the fix, 19 tests pass across ReducePartitionCommitHandlerSuite, WorkerStatusTrackerSuite, and MapPartitionCommitHandlerTest with Java 17 / Scala 2.12.
• spotless:check passes for the client and its upstream modules.

[yew1eb]

Verified locally: allocatedWorkers is a ConcurrentHashMap[String, ShufflePartitionLocationInfo] whose keys are written as workerInfo.toUniqueId (see LifecycleManager#handleRegisterShuffleResponse). ConcurrentHashMap.contains(Object) is the legacy Hashtable-style method that checks values, and since the values are ShufflePartitionLocationInfo (never equal to a WorkerInfo), the old guard was always false — the early SHUFFLE_DATA_LOST path introduced by CELEBORN-2166 has been dead code since then.

containsKey(workerId.toUniqueId) matches the key format exactly and is consistent with the lookups in WorkerStatusTracker#excludeWorkerFromPartition and CommitManager#handleCommitFiles. LGTM on the fix itself.

Optional nit: since we're touching this expression anyway, collect { ... }.nonEmpty could be simplified to exists { case (workerId, (status, _)) => ... } to avoid building an intermediate collection for a membership check.

[zaynt4606]

Thanks, updated to use exists.