No integration coverage for the uprobe `pid` (and `offset`) attach fields

The uprobe CRD exposes `pid` and `offset`, and the agent forwards both to bpfman over gRPC:

```
controllers/bpfman-agent/cl_uprobe_program.go:96-98
Offset: uint64(r.currentLink.Offset),
Target: r.currentLink.Target,
Pid: r.currentLink.Pid,
```

But nothing exercises either end to end. The integration test only ever attaches by function name:

```console
$ grep -rci -e pid -e offset test/integration/uprobe_test.go
0
```

and the example it deploys sets just a function and target:

```yaml
# examples/config/base/go-uprobe-counter/bytecode.yaml
- function: main.getCount
target: /go-target
```

So a regression that dropped `pid` on the wire would sail through CI green -- the probe would silently widen from one process to every process running the target, and no test would notice.

A `pid` test needs to prove scoping, not just that an attach with a pid succeeds: two processes running the same target, pid-filter one of them, and assert only that one's events are counted. The current single-process `go-uprobe-counter` example can't show it, so it'd want a second workload (or a second pod) and a count assertion that would fail if the filter were ignored.

`offset` is fiddlier to test portably -- you need the target symbol's actual file offset, which varies by build and arch -- so it's lower priority and could ride along in the same fixture rather than its own test.

Start with test/integration/uprobe_test.go and the examples/config/base/go-uprobe-counter/bytecode.yaml, then inspect the uprobe fixture and the agent forwarding code in controllers/bpfman-agent/cl_uprobe_program.go. Add coverage using two processes or pods running the same target, configure a pid filter, and run the integration suite. Done means only the selected process produces counted events; offset coverage may share the fixture if a portable symbol offset is available.

Written by the indexing model from the issue text.