In-Kernel Lua examples fail because of non-integer key types

I know that the JIT bytecode to BPF compiler is practically unmaintained and does not receive much attention, but I am using it currently. Anyway, the `kprobe-latency.lua` example does not work, yielding this error:
```

stack traceback:
/usr/share/luajit-2.1/bpf.lua:1380: in function '__index'
/usr/share/luajit-2.1/bpf.lua:665: in function 'MAP_INIT'
/usr/share/luajit-2.1/bpf.lua:705: in function
[C]: in function 'xpcall'
/usr/share/luajit-2.1/bpf.lua:1383: in function 'compile'
/usr/share/luajit-2.1/bpf.lua:1500: in function 'kprobe'
/kprobe-latency.lua:30: in main chunk
[C]: at 0x5652829fafa0
luajit: /usr/share/luajit-2.1/bpf.lua:1502: attempt to index local 'prog' (a nil value)
stack traceback:
/usr/share/luajit-2.1/bpf.lua:1502: in function 'kprobe'
/kprobe-latency.lua:30: in main #chunk//
[C]: at 0x5652829fafa0

```

After careful inspection of the resulting JIT bytecode, I identified the problem (I think). My hypothesis is that the problem lies in `probe_read` in `builtins.lua.` Specifically, when the bytecodes for calling the probe_read helper are emitted, the result is placed in the 0 register. After calling, the VM state is updated to reflect that the VM tmpvar is not active. However, I believe the the register that the return value was placed in, in this case 0, should be persisted back to the `dst` variable. Otherwise, the return value from `probe_read` is not recorded anywhere in the VM state:

```
builtins.lua:
builtins[probe_read] = function (e, ret, dst, src, vtype, ofs)
...
e.emit(BPF.JMP + BPF.CALL, 0, 0, 0, HELPER.probe_read)
-- This updates the VM to locate the destination variable's value in the emitted register.
e.V[dst].reg = e.V[e.tmpvar].reg
--
e.V[e.tmpvar].reg = nil -- Free temporary registers
```

I haven't conclusively tested this because I don't have a thorough mental model of the system, but it does (seem) to fix this error in particular. An inspection of the resulting BPF program seems to yield expected results, too.

Sorry for the messy formatting of the proposed patch. If anyone is interested in this matter I am happy to share more diagnostic information or run tests to confirm this issue.

For context, I am building against kernel version 6.12.27 using Buildroot 25.08 as the build environment, and happy to share my buildroot config to establish a similar environment.

Start with builtins.lua and the probe_read implementation, then trace the emitted bytecodes and VM register state described in the issue. Reproduce with kprobe-latency.lua on the stated kernel environment and verify that the probe_read return value remains associated with its destination so the example completes without the reported error.

Written by the indexing model from the issue text.