fix: retry nodejs/python uprobe attach on transient failure

[ybucci]

What

instrumentNodejs/instrumentPython mark nodejsChecked/pythonGilChecked as done unconditionally, even when the eBPF uprobe attach fails. Since instrument() calls them exactly once per process, a single failed attach permanently disables Node.js/Python instrumentation for that process — silently, with no retry and no error surfaced anywhere but the log line.

Why it matters

This fires often right after the agent restarts (or on any container-restart burst): the registry rescans every already-running container at once, so many processes race to attach uprobes against the same shared *ebpf.Program (t.uprobes[...]) at the same moment. Observed on a real cluster:

E nodejs.go:32] pid=X ...: failed to attach nodejs uprobes: prog cannot be nil: invalid input
E nodejs.go:32] pid=Y ...: failed to attach nodejs uprobes: symbol uv__io_poll not found

--instrumentation-delay doesn't help here — it only protects processes that just started; already-running processes rescanned on agent restart are already past the delay, so they all attach concurrently with zero spacing.

Net effect: whether a given container ends up with working Node.js/Python metrics is effectively random per restart, with no operator-visible signal that it happened (the Node.js/Python inspection tab in the UI just silently doesn't show up).

Fix

instrumentNodejs/instrumentPython now return bool (done or not) and only set checked = true on success, on a definitive "not this language" result, or after maxInstrumentAttachAttempts (5) tries. instrument()'s existing backoff loop (already used for the "process not ready yet" case) now keeps retrying until both are resolved, instead of unconditionally returning after the first pass.

Verification

Built and deployed to a real k3s cluster (patched v1.35.2). Confirmed via logs:

• Processes that failed with prog cannot be nil (the concurrency-race case) succeeded on retry within ~1-2s.
• Processes that failed with symbol uv__io_poll not found (a separate, deterministic issue — worth its own investigation, not addressed here) correctly exhausted retries and gave up after 5 attempts, same as before.

Happy to adjust the retry count/backoff or split this differently if you'd prefer a different shape.

[def]

The overall idea is that if we couldn't instrument the app on the first attempt, there's almost no chance that a second attempt will succeed. You mentioned that prog cannot be nil is related to "the concurrency race" case. Could you elaborate on that?