sys scheme: fix MSR open path-strip bug causing ENOENT

The sys scheme dispatcher stripped the 'msr/' prefix before
calling msr::open(), but msr::open() also strips 'msr' from the
path. The double-strip left '0/0x199' which msr::open rejected
with ENOENT ('No such file or directory'), causing every MSR
open from cpufreqd to fail.

Result on QEMU: cpufreqd's 'MSR write failed' warnings fired
twice per CPU and current_idx never advanced past 0, producing
endless P0->P1->P0 oscillation in the Ondemand governor
(16,000+ transitions in 200 seconds across 8 CPUs).

Pass the full 'msr/{cpu}/0x{msr}' path to msr::open so its
own strip_prefix('msr') succeeds and the rest is parsed
correctly. Same fix applies to any other scheme registered
the same way.

src/scheme/sys/mod.rs

@@ -170,8 +170,12 @@ impl KernelScheme for SysScheme {
             // /scheme/sys/msr/{cpu}/0x{msr} — Phase G.1: MSR R/W scheme
             // for cpufreqd and redbear-power. Open is parse-only; reads
             // and writes happen via the handle's read/write paths below.
-            let msr_path = path.strip_prefix("msr/").unwrap_or("");
+            // Pass the full "msr/{cpu}/0x{msr}" path to msr::open so it
-            let handle = msr::open(msr_path, _flags, _fcntl_flags, &ctx, token)?;
+            // can do its own strip_prefix("msr") and parse the remainder.
+            // Stripping here (the previous behavior) left "0/0x199"
+            // which msr::open's strip_prefix("msr") rejected with ENOENT,
+            // causing every MSR open to fail and cpufreqd to oscillate.
+            let handle = msr::open(path, _flags, _fcntl_flags, &ctx, token)?;
             // Store the (cpu<<32 | msr) handle in the data buffer; the
             // path string is intentionally omitted (the static array
             // version would require 'static lifetime which user_buf