gpu: say whether the injection happened, and document how to install it (#121)

[dpsoft]

CUDA_INJECTION64_PATH fails open and silent. A driver that cannot load the library carries on
as though the variable were never set: nothing logged, workload runs normally, profile comes out
empty. "The shim is broken" and "this workload launched no kernels" are indistinguishable in the
output — which is how a shim requiring glibc 2.42, unloadable in every mainstream PyTorch image,
went unnoticed.

The check

The mapping is the one observable that separates the two, and it is the same fact enrolment already
keys on. gpuprobe.ShimIsMappedIn exports it; the tool watches for the shim appearing in the
workload's maps while the workload is alive, and when a run samples no launches it says which
cause it was:

	reported
launches > 0	nothing — a line confirming the obvious on every healthy run trains people to skip the output
none, shim mapped	injection worked, the adapter reported nothing → points at the perfagent-cupti lines
none, shim absent	names the file and pid, says this is what a failed injection looks like, suggests nvidia-portable

Two limits are stated rather than hidden: it inspects this pid, so a workload launched through a
wrapper script does its CUDA work in a child it cannot see; and it only ever produces a diagnostic,
never a failure. A malformed shim is caught earlier still, at attach, with its own message.

Tested both ways, deliberately

A check that can only answer "no" would report every run as broken; one that can only answer "yes"
would confirm injections that never happened, which is worse than not checking. So the test asserts
both against the same process. A path that is not a file is an error, not a confident
negative — answering "not injected" for a mistyped path sends the reader to the driver instead of
to their own command line.

Docs

docs/gpu-injection.md is the install guide this issue implied but never had: the mechanism and
its two dangerous properties, which shim to build and why that distinction is not cosmetic, that
CUPTI is the operator's to supply and where it usually already is, delivery on bare metal / in a
container / in Kubernetes, how to verify, and the capability set including why CAP_SYS_ADMIN is
absent by design.

It also states what is still missing rather than implying completeness: no published image for
the init-container pattern, and no attach-to-running-process mode — which is what stops the
Kubernetes sidecar shape from working at all (#124).