fix: generate libv4l t64 compatibility package

[andrescera]

Summary

Build a real arm64 libv4l-0 compatibility package during RK3588 userspace staging. It depends on Trixie’s libv4l-0t64 and contains one collision-free symlink whose basename satisfies the pinned rockchip-multimedia-config postinst’s literal dpkg -L lookup.

The package is classified as BSP input and explicitly installed first in the same mkosi-install transaction as rockchip-multimedia-config. The upstream .deb and its pinned SHA-256 remain unchanged.

Testing

• Built with ./build <board> — full image build not repeated; DRY_RUN=1 INSTALL_BOOT_BSP=0 ./build rock-5b-plus passed
• Tested in a real arm64 Debian Trixie container with Debian libv4l-0t64 and the exact pinned Rockchip .deb; postinst exited 0, the compatibility link resolved to the t64 library, and the copied bytes matched
• bats tests/package-contract.bats — 108/108 passed
• Full ./run-tests passed using the native Docker daemon wrapper
• Shellcheck and LSP diagnostics passed for changed shell sources

Docs

• Updated docs/trixie-package-resolution.md and AGENTS.md with the t64/dpkg rationale and ownership boundary

Checklist

• Minimal packages/services added
• Shell scripts are defensive and chroot-safe
• Commit messages follow conventions

Risks

The compatibility package is intentionally arm64/RK3588-specific and pins the Trixie 1.30.1 library path. Contract tests fail if its metadata, sole payload, target, staging class, or transaction wiring drifts.