Generally, yes, fetched jobs are those picked up by the workers. But result of
FetchedJobs() is rather storage implementation-specific, for example, SQL Server storage always returns zero
When the worker is free, It tries to pick next pending job from the queue. When the job is found, the worker needs to secure it somehow for itself, so other workers won't start processing it too. There are a few ways of doing so.
For example, SQL Server storage immediately deletes the job from queue, but keeps transaction uncommitted until the worker has finished processing. And in case it failed to finish (exception, server reboot etc.), transaction is automatically rolled back and the job returned to the queue, to be picked up by other workers. So technically the jobs are really not fetched from the queue, but struggle on the verge of life and death like Schrödinger's cat
But many other storages can't do so, so they use another approach: the moment they pick a job, they brand it with a timestamp (FetchedAt), so other workers won't touch it for the time being (de-facto 24h for many Hangfire storage implementations). During this time, job is not removed from the queue (its Queue field remains intact), but neither is picked by other workers. That's what is fetched.
After it finished processing, the worker will finally remove the job from queue (by erasing both Queue and FetchedAt fields). And even if it failed, the job would eventually be picked by another worker after timeout. Obviously, the latency in this case would be much greater, compared to a transaction, but it is still the only choice for many storages.