chore(ebpf): Add Linux CO-RE eBPF feasibility spike

[mostafa]

What is the purpose of this PR / why it is needed?

Validates that Fibratus can load CO-RE eBPF programs on Linux with the hard runtime contract needed for a future eBPF event source: kernel >=5.9, usable /sys/kernel/btf/vmlinux, ring buffers, and iter/task process baseline capture without bpf_d_path. The spike also proves shared-map replacement across separately generated objects, best-effort /proc enrichment, and race-safe startup reconciliation keyed by PID + start boot time. A feasibility note audits Windows coupling and every ps.Snapshotter consumer that must move before a Linux build can land.

What type of change does this PR introduce?

---

/kind improvement

Any specific area of the project related to this PR?

---

/area instrumentation

/area deps

/area build

Special notes for the reviewer

---

• Throwaway spike lives under internal/ebpf/spike with committed bpf2go artifacts. Ordinary builds do not require clang; regenerate with internal/ebpf/spike/generate.sh.
• Runtime probe helpers are in internal/ebpf.ProbePrerequisites. iter/task attach remains the conclusive iterator check inside the spike runner.
• Validated in a privileged Docker Desktop LinuxKit 6.12 container with kernel BTF and tracefs mounted. Example successful run showed pending hot events queued during baseline and replayed (pending_queued/replay_applied > 0).
• No Fibratus CLI/runtime behavior changes on Windows.

How to reproduce the spike:

# privileged Linux host/container with /sys/kernel/btf/vmlinux and tracefs
go test ./internal/ebpf -count=1
SPIKE_DURATION=1s go run ./internal/ebpf/spike/cmd/spike

Does this PR introduce a user-facing change?

---

No.