TaskBuilder should force Reacquire when a task finishes while yielded

[JanProvaznik]

Context

TaskHost tracks yield state via _yieldThreadId (TaskHost.cs:106), and Yield() verifies you are not already yielded (TaskHost.cs:361), but there is no enforcement after Execute() returns. If a third-party task calls IBuildEngine3.Yield() and returns from Execute() without calling Reacquire():

1. RequestBuilder.Yield() sets _blockType = Yielded and tells the engine the entry is Waiting
2. The task returns normally - the builder thread never blocks (it never reaches the WaitHandle.WaitAny in Reacquire())
3. The engine may activate another builder since the entry appears to be Waiting
4. The original builder thread continues through the rest of TargetBuilder -> BuildTargets returns

This is a protocol violation by the task, but the engine should defend against it.

Proposal

After taskExecutionHost.Execute() returns in TaskBuilder.ExecuteInstantiatedTask (TaskBuilder.cs:832), check whether the task left the node in a yielded state (via TaskHost._yieldThreadId != -1) and if so, force a Reacquire() before continuing. This would:

• Restore the engine one-active-builder invariant
• Log a warning so task authors can fix their code
• Prevent any downstream issues from the inconsistent state

Affected code

• TaskBuilder.cs:832 - after taskResult = taskExecutionHost.Execute()
• TaskHost.cs:106 - _yieldThreadId field (currently private, would need to be exposed or checked via a property)

Why this matters

The engine scheduling correctness depends on the invariant that only one builder is active per node at a time. A yield-without-reacquire silently breaks this invariant. Currently the only defense is that all built-in tasks use try/finally around Yield()/Reacquire() (ToolTask.cs:957-1027, Unzip.cs:104-166, ZipDirectory.cs:78-146), but third-party tasks have no such guarantee.

[rainersigwald]

Solidly in the "we don't do that already???????" bucket. Agree that we should.