ContinueJobWith/RecurringJob.AddOrUpdate queue-string overloads silently don't control real dispatch, only set Job.Queue metadata

Calling BackgroundJob.ContinueJobWith(parentId, "myqueue", methodCall, options) or RecurringJob.AddOrUpdate(id, "myqueue", methodCall, cron) does not actually enqueue the resulting job onto myqueue. It runs on default instead. The dashboard and InvocationData.Queue still show myqueue, so this is easy to miss.

Root cause (checked against v1.8.0 and main):

• ContinueJobWith(client, parentId, queue, methodCall, nextState, options) builds new AwaitingState(parentId, nextState ?? new EnqueuedState(), options). None of the queue-string overloads pass nextState, so it falls back to new EnqueuedState(), whose parameterless constructor hardcodes the default queue. The queue argument only reaches client.Create(queue, methodCall, state), which calls Job.FromExpression(methodCall, queue) and sets Job.Queue. That's informational metadata only, not the dispatch queue.
• ContinuationsSupportAttribute.OnStateElection later reapplies that stored NextState as is when the parent finishes. It never checks Job.Queue to correct it.
• Same bug shape for RecurringJob.AddOrUpdate(id, queue, methodCall, cron). That overload forwards to the RecurringJobOptions overload with a plain new RecurringJobOptions(), never setting QueueName from the given queue. That overload uses queue only for Job.FromExpression(methodCall, queue) metadata. RecurringJobManager.AddOrUpdate then sets the recurring job's actual Queue field from options.QueueName, which stays null/default, even though the recurring job's own storage feature check (JobStorageFeatures.JobQueueProperty) confirms the storage supports per-job queues.

Related issues, though none cover these specific overloads: #1900, #1695, #2226.

Repro: create a continuation with an explicit queue, then check HangFire.JobQueue for the resulting job. It ends up under default, not the queue that was passed in.

The 1.8.0 release notes describe "first class queue support" with an example almost identical to ContinueJobWith(id, "queue", methodCall). That makes this look like a real gap between the documented behavior and the shipped code, not intentional legacy behavior. Either fix these overloads to build new EnqueuedState(queue), or update the docs to state that [Queue] is the only reliable mechanism for continuations and recurring jobs.