Image ships the RKNPU kernel driver but not librknnrt.so, so the NPU is unusable out of the box

The CB2 image ships the RKNPU **kernel driver**, but not the userspace runtime library it needs. As a result the NPU is unusable by any RKNN application on a stock image, even though the hardware and driver are both fine.

Tested on a freshly flashed `BIGTREETECH-CB2 3.1.0-26.08.0-trunk` (kernel `6.1.115-btt-rockchip64`).

**The driver side is perfect:**

```
[drm] Initialized rknpu 0.9.8 20240828 for fde40000.npu on minor 1

/dev/dri/card1 root:video 660 /devices/platform/fde40000.npu/drm/card1
/dev/dri/renderD129 root:render 660 /devices/platform/fde40000.npu/drm/renderD129
```

Both nodes are readable/writable by the default `biqu` user — thank you, that part is right out of the box.

**But the userspace library is absent entirely:**

```
$ ls /usr/lib/librknnrt.so /usr/lib/aarch64-linux-gnu/librknnrt.so
ls: cannot access ...: No such file or directory

$ find / -name 'librknnrt.so*' 2>/dev/null
(no output)
```

Every RKNN program links against `librknnrt.so`, so without it the NPU simply cannot be reached. Rockchip does not publish a static `librknnrt.a`, so applications cannot bundle it either — it has to come from the board image.

### Request

Would you consider shipping `librknnrt.so` in the default CB2 image, matched to the RKNPU driver version the image ships (0.9.8 here)?

Rockchip distributes it in [`airockchip/rknn-toolkit2`](https://github.com/airockchip/rknn-toolkit2) under `rknpu2/runtime/Linux/librknn_api/aarch64/`. It's a single ~7 MB file in `/usr/lib`. Shipping it from the image (rather than each application guessing a version) is also the safer option, since the library and the kernel driver need to be compatible.

### Why it matters in practice

I maintain [PiNozCam](https://github.com/DrAlexLiu/OctoPrint-PiNozCam), an open-source AI print-failure detector that runs entirely on the printer host — no cloud, no subscription. On CB2 it uses the RK3566 NPU through RKNN.

Measured on this board, back to back, same 640x384 input and same postprocessing, 6 runs each (median):

| backend | median per frame |
|---|---|
| **RK3566 NPU** (after I installed `librknnrt.so` 2.3.2 by hand) | **257 ms** |
| CPU fallback (4x A55, same board) | **1544 ms** |

A **6.0x** difference. End to end through the real application (camera fetch and
pre/post-processing included) the NPU path measures ~241 ms per frame.

So the NPU is genuinely worth having, and the board is one file away from delivering it. Right now a user installing an RKNN application on a stock CB2 gets the slow path with no obvious indication why — the hardware looks present, the driver is loaded, and only the library is missing.

(That last part is on me to surface better in my own software, and I'm fixing it on my side. But the image change would mean nobody has to notice in the first place.)

Happy to test any image you'd like verified on real hardware.

Start by locating the CB2 image's package or build entry point and checking how the RKNPU kernel driver is included. Add the matching aarch64 librknnrt.so to the default image, then verify on a freshly flashed stock image that an RKNN application can load the library and use the NPU.

Written by the indexing model from the issue text.