[Bug] [Zeta] CooperativeTaskWorker resolves its class loader from the shared executionContexts map instead of its own generation's context

### Search before asking

- [x] I had searched in the issues and found no similar issues.

### What happened

Split out from the review of #11727, where it was found and deferred with
reviewer agreement rather than widening that PR further.

#11727 makes `BlockingWorker.run()` resolve its `TaskGroupContext` and class
loader from the tracker's own generation-scoped `ownedContext`, so a stale
`taskDone()` from an earlier restore generation cannot hand it the wrong
generation's context.

`CooperativeTaskWorker` is the sibling path for thread-shared tasks and still
resolves from the shared, location-keyed `executionContexts` map. Since
`TaskGroupLocation` (`{jobId, pipelineId, taskGroupId}`) is reused verbatim
across restore generations, the same cross-generation mismatch is reachable
there.

Scope: only reachable under `task_execution_thread_share_mode: ALL` or `PART`.
The default (`OFF`) routes tasks through `BlockingWorker`, which #11727 already
fixes.

### SeaTunnel Version

dev

### Are you willing to submit PR?

- [x] Yes I am willing to submit a PR!