gpu: fire the sampled probe before the batched add

[dpsoft]

Closes #67. main's GPU gate is currently red because of this — it merged with #61 and CI never noticed, because the gate needs cap_bpf/cap_perfmon and skips without them.

The race

The producer queued the launch batch, then the exec batch, then the sampled probe. When one launch was both the record that filled the launch batch and the one the sampler picked, the exec batch landed between the twins, released the deferred queue, the launch went out stackless, and its stack parked in pendingStacks with nothing to join.

gpuprobe/sampledstacks.go:14-40 documented this and quantified it — "24 of 250 captures at 2000 launches; none at 500".

"None at 500" was arithmetic, not luck. Batches flush every 32 records; the old sampler took every 8th launch; a multiple of 8 is never ≡ 31 (mod 32). #50's jittered stride made sampled ordinals irregular, so one eventually lands on a batch boundary. The aliasing bug had been masking this race.

Measured on main, two consecutive privileged runs:

stack attach: sampled=58 resolved=58 attached=57 pending=1 missing=0 uncorrelated=0
gpu join:     500 executions, all exact; 500 launches, all matched; no anomalies

The fix

Both producers fire the unbatched gpu_launch_sampled_v1 probe before the batched add(). The record is still fully built first — the sampled record reads l.kernel_id/l.correlation — so only the two probe fires swapped. No ABI change, no sampler change, no consumer change.

This makes batched-first unreachable rather than rare: a record cannot be in a batch before add() puts it there, so no flush on any thread can carry the twin past the probe.

The adapter case was worse than the issue described

On the stub, the interleave needs one launch to fill the batch. On the CUPTI adapter the exec batch is flushed by the CUPTI worker thread and the drain timer, never by on_launch — so it was a genuine thread race with a small but real window. PendingStacks:0 on the CUDA path across nine measured runs meant we kept missing that window, not that it could not be hit.

Testing it without privilege

The bug is only observable under capabilities, which is how it reached main. So the producer's mechanism is now testable without any: shim/stub/probe_order_test.cc links the real stub.cc, patches the probe sites with int3 (the trick probe_args_test.cc already uses) and reads the wire order back from the trapped registers.

Pre-fix:

period=1 launches=64:    2 of 64 sampled launches had their BATCHED record emitted
                         before their sampled twin (first: correlation 32, batched tick 32, sampled tick 33)
period=8 launches=2048:  7 of 253 sampled launches ... (first: correlation 32, batched tick 4, sampled tick 5)

7-of-253 at 2048 launches reproduces the demo run's 24-of-250 rate with no privilege at all. Plus a source-order pin covering both shims — the only unprivileged guard the CUPTI adapter can have — and a positive consumer-side counterpart.

Deliberately not written: a consumer test driving the hostile order. Such a test can only pass if the consumer changes, and the argument here is that it should not — once the launch is at the sink there is nothing left to attach to. Rejected for the same reason: holding the deferred queue (hands every exec to the sink ahead of its own launch, and needs a magic number) and LaunchCache reattachment (the Consumer talks to a gpu.EventSink and does not own the cache; reaching it breaks "one launch in, one launch out").

Gate

assert.Zero(PendingStacks) and assert.Equal(wantSampled, StacksAttached) at rest, plus a stack attach: identity line. The previously failing assertion is unchanged and nothing was weakened.

Predicted, derived before any run: sampled=58 resolved=58 attached=58 pending=0, timeline sampledLaunches=58. CUDA path expected unchanged at 505 == 505, PendingStacks:0.