eBPF collector is x86-only; arm64 decodes syscall args incorrectly

## Summary

The eBPF collector is compiled x86-only, so `--mode ebpf` does not decode syscall arguments correctly on non-x86 kernels (notably `linux/arm64`, which we now ship a release binary for).

## Details

The BPF object is built with a hardcoded arch flag in the `Makefile`:

```make
ebpf:
cd internal/ebpf && clang -O2 -g -target bpf -D__TARGET_ARCH_x86 \
-mllvm -bpf-stack-size=1024 \
-c collector.bpf.c -o collector_bpfel.o -I./headers
```

`collector_bpfel.o` is then embedded once (`//go:embed`) and used for every `GOARCH`. On arm64 the syscall entry ABI differs, so `struct trace_sys_enter` argument extraction is wrong and file/network paths/args come out garbled or empty.

Since v0.2.0 publishes a `linux/arm64` binary, a user could reasonably run `ltm start --mode ebpf` on an arm64 box and get bad data.

## Current behavior

- `linux/amd64` eBPF: works (verified on Ubuntu 24.04 / kernel 6.8).
- `linux/arm64` eBPF: attaches but syscall args decode incorrectly.
- demo mode + all storage/query features: fine on every arch.

Documented as a known limitation in `AGENTS.md` ("x86_64 only for now").

## Suggested fix

- Build a per-arch BPF object (`__TARGET_ARCH_x86` vs `__TARGET_ARCH_arm64`) and select the right embedded object at runtime by `runtime.GOARCH`, or build CO-RE-portable programs.
- Until then, make `--mode ebpf` on unsupported arches fail fast with a clear message instead of silently recording bad data.

## Scope

Small / low priority — isolated to `internal/ebpf` (Makefile + object embedding + one guard). No impact on amd64 or on non-eBPF features.