fix: kernel must use /sbin/init, not piCore's /init

Root cause of the 'Run /init as init process' -> immediate SIGSEGV panic on
the generic ARM64 boot: piCore64's rootfs ships a /init script at the rootfs
root, and the kernel's init search order picks /init over /sbin/init. piCore's
init then exec's something incompatible with our environment and segfaults.

Two fixes:
1. inject-kubesolo.sh now removes the upstream /init after replacing
   /sbin/init. This is the structural fix — the rootfs no longer has the
   conflicting entry-point.
2. grub-arm64.cfg passes init=/sbin/init explicitly. Belt-and-suspenders in
   case any future rootfs source re-introduces /init.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

build/grub/grub-arm64.cfg

@@ -64,7 +64,7 @@ fi
 menuentry "KubeSolo OS (${slot_label})" {
     echo "Booting KubeSolo OS from ${slot_label}..."
     echo "Boot counter: ${boot_counter}, Boot success: ${boot_success}"
-    linux /vmlinuz kubesolo.data=LABEL=KSOLODATA console=ttyS0,115200 console=ttyAMA0,115200
+    linux /vmlinuz init=/sbin/init kubesolo.data=LABEL=KSOLODATA console=ttyS0,115200 console=ttyAMA0,115200
     initrd /kubesolo-os.gz
 }
 
@@ -76,7 +76,7 @@ menuentry "KubeSolo OS (${slot_label}) — Debug Mode" {
 
 menuentry "KubeSolo OS — Emergency Shell" {
     echo "Booting to emergency shell..."
-    linux /vmlinuz kubesolo.shell console=ttyS0,115200 console=ttyAMA0,115200
+    linux /vmlinuz init=/sbin/init kubesolo.shell console=ttyS0,115200 console=ttyAMA0,115200
     initrd /kubesolo-os.gz
 }