About manually scheduling and persistence of workflow

When the manually schedule service us used to schedule workflows you have to be aware of:

1. The workflows is started by following statement: manualScheduler.RunWorkflow(wfInstID);

2. When this statement is executed the workflow is running on the thread which has executed the code above as long the workflow enter either an event handler or queue awaiting state (which is more or less the same).

3. If the queue is running and the runtime decides to persist the workflow (Leaving of transaction scope, if configured by entering of delay or by leaving of the activity marked as PersistOnClose) the workflow will be persisted and it will continue the execution. If the execution is continued after persisting (that is in a case if next activity is not event handler) it is continued at the same thread as before persisting.

4. When the workflow enter awaiting state (handler or queue event subscription), there must be a thread outside of WF which will fire event and force the workflow to run. Here is an example:
testSvc.FireEvent(someParams, instID);

manualScheduler.RunWorkflow(instID);

Note that this code is run on the on some different thread than the thread which has started the workflow. After invoking of RunWorkflow go to Point 1.
At this point there is one interesting case, when the workflow enters a delay state. Delay state internally subscribes for waiting on queue events and creates the thread which is responsible to fire (post the message in the queue) an internal event, which wakes up the workflow. In this case the workflow runs on the some thread which is not under your control.
The only thing to take a control of this thread is to reemployment delay activity as your own one, which will wait on event fired by your thread.
To take a control of this behavior you would need to write tracking service which would notify your code when a delay activity has expired. After receiving of this event it could be possible to run the workflow at any thread you choose.