A launch abandoned before delivery leaves its process to the next launch

[glslang]

Raised in review on #139 and deferred there, because the obvious fix is a trade rather than a fix
and wants deciding on its own.

The gap

launch_process_begin issues a CreateProcessWide that DbgEng defers to the next WaitForEvent,
and hands back a PendingTarget guard. Drop that guard before any pump and Arrivals::forget
takes its still-Waiting entry out of the register, leaving no exclusion behind — there is nothing
to leave, since the open was never delivered a process and nobody knows which one it would have got.

The create is still queued. So:

1. launch_process_begin("a") — entry registered, create deferred.
2. the guard is dropped — entry removed, no exclusion.
3. launch_process_begin("b") — snapshot taken, and it cannot contain a's process, which does not
   exist yet.
4. one WaitForEvent materialises a, and it is new to b's snapshot, not attached and not
   named by any pending attach — so b's open claims it.
5. b's wait() returns Ok(()) with b's own process not yet at its initial break.

Why it is not simply "keep the entry"

That is the fix review proposed, and it closes step 4 for the ordinary case: the abandoned entry is
first in registration order, so it claims a and b waits for the next arrival.

What it does not have is anything to retire it by. A guard is what ends an entry's life, and this
one has none — so an abandoned launch that never starts leaves a registration that competes for
arrivals for the rest of the session. That case is not hypothetical: examples/deferred_arrival.rs
arm C measures a launch whose image does not exist failing inside the wait (Err(0x80070002) in
13 ms, no debuggee behind it). The ghost then takes the next launch's process and times that guard
out.

So the choice is a wrong Ok on every abandoned launch against a wrong timeout on every abandoned
launch that failed to start. The second fails closed and is rarer, which is an argument, but it is
a different bug rather than the absence of one — and it is the shape #136 stage 3 was written to
get rid of: an entry outliving its reader, with no signal that says when it is done.

Prior art in this repo

This is the residue of the ambiguity Arrival's doc comment recorded as accepted before #139
("the elimination is ambiguous for two launches pending at once"). #139 closed the two cases that
have a signal to close them with — both guards live, and delivered-then-dropped, where the claim is
inherited by the opens still waiting — and this is the third, which has none.

What would close it

Something that says an abandoned launch's create has been resolved, one way or the other. Options
not yet weighed against each other:

• retire an abandoned entry on the pump that fails, since arm C shows the failure surfaces
  there — bounded, but only for the failure mode it can see;
• make launch_process_begin non-deferred, so a dropped guard has a process to name;
• refuse to drop a launch guard silently — an explicit abandon() that pumps once.

None is obviously right and none is urgent: every caller in this crate and in windbg-mcp waits on
the guard it is given.

[glslang]

Measured, and both of this issue's load-bearing claims were wrong. #143 fixes half of it; the issue
stays open, narrowed to the other half.

The deferral reason does not exist

This issue was deferred because keeping the entry looked like a trade: nothing would retire one
whose launch never started, so a failed abandoned launch would leave a ghost taking the next
launch's process. That rested on deferred_arrival's arm C — "a launch whose image does not exist
fails inside the wait".

It fails at launch_process_begin: 0x80070002 in 1.5 ms, no guard returned. Arm C calls the
combined launch_process, which cannot tell begin from wait apart, so its description was an
interpretation rather than a measurement; worker.rs in windbg-mcp says the opposite and was right.
A launch that cannot start never produces a guard, so there is no entry to retire and nothing to
trade. examples/abandoned_launch.rs in #143 is the measurement.

The defect is real, and worse-observed than described

Reproduced precisely once the observation was right: a launch of ping.exe behind an abandoned
cmd.exe is delivered the cmd.exe.

Two earlier attempts at that observation passed while the defect was live, both worth recording:
counting processes when wait() returns says nothing, because one WaitForEvent realises both
queued creates (session 0 → 2 on a single pump); and asking whether the second program is listed
says nothing either, because membership is the weaker claim this crate is built on not confusing
with having stopped.

What is left

#143 keeps the abandoned entry so the create is accounted for — one entry absorbs one arrival,
so the next launch's wait() returns only once a second process has stopped, where before it could
return with its own process not yet created.

It does not make the next launch get its own process, and ordering cannot. deliver offers in
registration order and the abandoned entry is first, so it takes whichever process arrives first;
with both creates realised by one pump, which one the event names is a coin flip. Asserting the
image name failed about half of all runs with the fix in place — that is how this was found rather
than shipped.

So what remains here is identification, not accounting: telling two pending launches apart needs
something to match on rather than an order. This is the same residue Arrival's doc comment has
always described for two live launches — dbgscope#139 closed "both guards get the same arrival",
not "each guard gets its own" — so closing it would fix that case too.

The only candidate I can see is matching the image name from | against the launch's command line,
which breaks down for two launches of the same image and is a design decision rather than a patch.
Not urgent: every caller in this crate and in windbg-mcp waits on the guard it is given, so no
caller today has two launches pending at once.

[glslang]

The accounting half landed in #143. The identification half is declined for now, with the trigger
to revisit written down rather than left implied.

What is left

Two launches pending at once get distinct processes, but which one goes to which is arbitrary:
deliver offers in registration order, and one WaitForEvent realises both queued creates
(measured: session 0 → 2 on a single pump), so which one the event names is a coin flip. Asserting
the image name failed about half of all runs with #143 in place — that is how this was separated
from the accounting problem rather than shipped as one.

This is the same residue Arrival's doc comment has always described for two live launches;
dbgscope#139 closed "both guards get the same arrival", not "each guard gets its own".

Why it is not being built

Nothing can reach it. Both consumers launch one target at a time and wait inside the same
closure — a worker in windbg-mcp holds one target for its whole life and EngineOp has no second
opener. Two launches pending at once is not a state any caller today can produce.

There is no clean mechanism, and the generating choice is not ours to delete.
CreateProcessWide hands back no pid, which is what forces identification by elimination in the
first place. The candidates:

candidate	why not
match the image name from | against the command line	breaks for two launches of the same image, which is the likeliest collision — it adds a mechanism and keeps the bug
refuse overlapping launch guards	already weighed and rejected in Arrival's doc: contradicts the split PendingTarget exists for, and gives a legitimate call a new way to fail
pump inside launch_process_begin	defeats the two-step API — the deferral is the point of it

And the fix would be close to unobservable. PendingTarget::wait(self) -> Result<(), DbgEngError>
hands the caller no identity for the process it got, so a perfectly-identifying implementation would
change only which process the engine considers current afterwards — nothing a caller can name or
act on.

What would make it worth doing

Either of these, and the fix follows from it rather than being guessed at now:

• a caller that launches twice before waiting — at which point the ambiguity is reachable and
  the caller's own shape says what identity it needs;
• an API that hands back the launched process's identity (a pid on the guard, or on wait) —
  at which point there is something to match on, and identifying the arrival becomes the natural
  implementation of it rather than an extra mechanism beside it.

Until then this is a documented limitation rather than a bug anything can hit. Left open so the
measurement and the reasoning stay findable; it is not waiting on work.