fix: register uprobe programs before attaching, add opt-in --instrumentation-delay (B4a of #369)

[mayankpande88]

Summary

First part of B4 (#369): the uprobe-lifecycle fixes from upstream coroot-node-agent that apply here without its uprobe deduplication.

Change	Upstream	What it does
Register uprobe programs at load	port of coroot/coroot-node-agent@2c72586	Uprobe programs were registered inside the attach loop, interleaved with attaching tracepoints and kprobes. Events flow as soon as the first one is attached, and handleEvents was already running. A process handled before its uprobe program was registered failed to attach, was marked as checked and was never retried. It also meant t.uprobes was written while handleEvents read it. Now every uprobe program is registered right after the collection loads, before anything is attached.
--instrumentation-delay	coroot/coroot-node-agent@44e3e8e (Nikolay Sivko)	Optional delay before attaching Python GIL and Node.js event-loop instrumentation to a new process. Default 0 (off) here; upstream uses 30s. TLS probes aren't affected.

Not taken:

• 2fdd10d (uprobe leak on Process.Close): fix(tls): count TLS capture losses and fix the gaps they exposed #353 already closes links that arrive after Close.
• f8d437a (uprobe deduplication) and 0ae7f5a (delay for TLS uprobes): these rework how TLS probes are attached and need their own design and measurement. They're tracked in Port upstream coroot-node-agent v1.29.0 → v1.36.2 #369 as B4b.

Engineering detail

Why the delay defaults to 0: upstream added it to save attach cost on short-lived processes. Here Node.js tracing is already opt-in (--enable-nodejs-tracing), so the delay mostly covers the Python GIL probes. With about 300 short-lived Python processes a minute, it saved about 2.6 millicores of agent CPU (2290 vs 2134 ms over 60s), at the price of losing GIL metrics for each process's first 30s.

44e3e8e conflicts: upstream's instrumentDone channel belongs to its deduplication, so it isn't taken. The flag line follows this fork's flag style.

CI: gofmt, goimports, vet, golangci-lint, go test (excluding /containers) and the build all pass in a Linux container with Go 1.26.5.

Local e2e: I built agent binaries from this branch and from main and ran them as systemd services on a local Debian 12 VM (kernel 6.1).

• Delay off vs 30s, same binary: while about 300 Python processes that each live 2s were spawned over 60s, the agent used 2290 ms of CPU with no delay and 2134 ms with 30s.
• 30s delay: a long-lived Python process had its probes attached 30s after it started.
• TLS capture: for an HTTPS client (Python, OpenSSL) that was already running when the agent started, this branch counted 86 requests and main 82 in the same 50s window.

[gemini-code-assist]

Code Review

This pull request introduces an instrumentation delay configuration (--instrumentation-delay) to delay Python GIL and Node.js event loop instrumentation after a process starts. It also updates the eBPF tracer to register uprobe and uretprobe programs before tracepoints or kprobes are attached, ensuring no events are missed. Feedback suggests replacing time.After with time.NewTimer in the delay logic to prevent potential timer leaks if the process context is cancelled before the delay expires.