feat(os): OS operator kernels in CUBE + thin native effector (Steps 1 & 2)

- cubecode/src/cb.rs: Behavior descriptor bitflag (PURE/IO_HEAVY/HOT_PATH)
  encoded into HeaderFlags bits 13..15; C_OS_KERNEL=210 / C_OS_EFFECT=211
  coordinate bands; round-trip unit test.
- fix: HEADER_FLAG_BEHAVIOR mask was 0x7000 (bits 12-14) which grabbed the
  ENCRYPTED bit (12) and dropped HOT_PATH (bit 15). Corrected to 0xE000.
- store_code_cell/put_code_cell/header_for_code gain optional descriptor arg;
  all 12 prior call sites pass None (total change).
- CLI: prog K=<flag> tokens, kernel verb (links+descriptors), tick verb lays
  down the OS kernel call-graph (cfg->decide->summarize->tick), native-apply
  verb = thin effector (runs kernel in VM, reads computed result, emits effect).
- integration test os_kernels_live_in_cube_with_call_graph_and_descriptors.

Proven green via ./check quick (fmt+clippy -D warnings+tests).

STARTUP-README.md

@@ -58,19 +58,23 @@ is real. Each must be reproduced live, not asserted.
    3358720263; `cat .czyx.200.50.1.7` returns the record content. Unit tests in
    `path.rs` cover full/partial/rejected forms. **STATUS: DONE.**
 4. **Boot substrate** — the VM brings up CUBELinux as a storage layer the rest of
-   the OS reads/writes through. **DONE (systemd-managed, 2026-08-13)**: units
-   `cube-os-state.service` (oneshot, writes boot manifest + machine identity +
-   boot history to `/cubefs/c200/z001|z002|z003`) and `cube-os-klog.service`
-   (streams kernel ring buffer to `/cubefs/c200/z004`) run at boot; both enabled
-   + active; state survives a FULL power cycle (verified 2026-08-13: rebooted the
-   VM, boot history showed multiple boots, manifest unchanged).
-   **ALSO (2026-08-13): real OS operational data** — `cube-os-snapshot.service` +
-   `cube-os-snapshot.timer` (every 5 min + 30s after boot) write genuine OS state
-   (running units, network, resources, journal) into `/cubefs/c200/z010/y001/xNNN`
-   (rolling 3-digit counter, x-axis is u16→3-digit per cubefs path model).
-   Verified: snapshot survives daemon restart; the OS wrote a NEW snapshot on a
-   fresh boot after a full power cycle; inode == packed CZYX. **STATUS: DONE
-   (auxiliary layer; not yet the root fs).**
+   the OS reads/writes through. **DONE (systemd-managed, 2026-08-13)**: the OS
+   boots and **writes itself as explicit CZYX coordinate calls to the cube-server
+   daemon** (the spec Phase 2/3 "cube-native" substrate path), NOT through the
+   FUSE mount. Per user direction, the FUSE view (`/cubefs`) is OPTIONAL — the
+   durable coordinate store is the persistence; POSIX paths are a convenience.
+   - `cube-os-state.service` (oneshot) writes boot manifest + machine identity +
+     boot history to `c200/z001|z002|z003` via `cubec --socket ... rawput`.
+   - `cube-os-klog.service` streams the kernel ring buffer to `c200/z004` (CZYX).
+   - `cube-os-snapshot.service` + `cube-os-snapshot.timer` (every 5 min + 30s
+     after boot) write genuine OS state (running units, network, resources,
+     journal) into `c200/z010/y001/xNNN` (rolling 3-digit counter persisted in
+     `c200/z010/y002/x001`).
+   All three units depend ONLY on `cube-server.service` (the daemon socket), not
+   on `cubefs.service`, so a FUSE mount failure can never wedge OS bring-up.
+   Verified: manifest reads "backing-store: cube-server @ /run/cube/cube.sock
+   (CZYX coordinate calls, no FUSE)"; snapshot + manifest survive a
+   `systemctl restart cube-server`. **STATUS: DONE (auxiliary layer; not yet the root fs).**
 
 ---
 
@@ -153,24 +157,36 @@ missing.
       random material on each boot → every sealed record became unopenable.
   Regression guards `durable_sealed_record_survives_restart` + `open_does_not_
   clobber_sealed_record` live in `cubesys/src/commands.rs`; `./check` is green.
-- Boot substrate (next deepening): make the cube the OS's *default* storage for a
-  real tree — e.g. have a service write `/etc` or `/var/log` operational files
-  through the cube by default. Currently the cube holds OS *state* (manifest/
-  identity/klog/snapshots) but the root fs is still ext4. The magic-prefix
-  "open by CZYX" FUSE passthrough is the natural next step (a path like
-  `/cubefs/.czyx/200.1.1.1` resolves directly to the coordinate), and a
-  loop/overlay over a cube-backed file would let the OS treat the cube as a real
-  block device.
+- Boot substrate (next deepening): **the substrate itself is done** — the OS
+  boots and persists its state (manifest/identity/klog/snapshots) as explicit
+  CZYX coordinate calls to the daemon (verified, durable across daemon restart).
+  Two honest gaps remain before a *real tree* on the cube:
+  (a) **cubefs directory model** — cubefs only maps `c<C>/z<Z>/y<Y>/x<X>` with the
+      `x` axis as a fixed 3-digit file leaf; nested dirs and arbitrary POSIX
+      filenames (syslog, wtmp, config files) are NOT addressable. So binding a
+      real OS tree (overlay/loop) onto cubefs is **blocked** until cubefs grows
+      proper nested-directory + rename/whiteout semantics (overlayfs currently
+      rejects cubefs with EINVAL — missing RENAME_WHITEOUT/opaque-dir support).
+      This is a Level-B crate feature, not a systemd change.
+  (b) **root fs / PID 1** — making the cube the literal rootfs is Phase 3 kernel
+      work (custom initramfs + pivot_root, daemon as init). Heavy, image-bake,
+      off-peak only. The current deployment keeps ext4 root + CZYX-call OS state,
+      which is the spec's Phase 2 target.
+  The CZYX-call substrate (not FUSE) is the spec-intended path; FUSE remains an
+  optional read/debug view.
 - IMAGE PROVISIONING: `build_vm.sh` (host, /root/build_vm.sh) now bakes the full
   durable stack into a from-scratch image — `cube-server.service` (daemon),
-  `cubefs.service` (durable FUSE view OF cube-server, NOT --seed), and the
-  three `cube-os-*` units + scripts + `cube-os-snapshot.timer` (OS state / klog /
-  operational snapshots written into the cube store at C=200). All enabled in the
-  chroot. So a fresh bake IS reproducible; the prior caveat (units living only in
-  the guest fs) is closed as of 2026-08-13. NOTE: the running VM was provisioned
-  manually before this was wired into build_vm.sh; re-running `build_vm.sh`
-  regenerates from clean and is a heavy (~24G qcow2 + debootstrap) operation —
-  trigger it off-peak, not while the machine is in use.
+  `cubefs.service` (OPTIONAL durable FUSE view OF cube-server, NOT --seed), and
+  the three `cube-os-*` units + scripts + `cube-os-snapshot.timer`. IMPORTANT
+  (2026-08-13 fix): the `cube-os-*` units now write via `cubec --socket
+  /run/cube/cube.sock rawput/get` (CZYX calls) and depend ONLY on
+  `cube-server.service` — `cubefs.service` was REMOVED from their Requires/After,
+  so a FUSE mount failure can no longer wedge OS bring-up. `cubefs.service` itself
+  was hardened (ExecStartPre unmounts any stale mountpoint; BindsTo cube-server)
+  to survive a daemon restart without the old crash-loop. All enabled in the
+  chroot. So a fresh bake IS reproducible; re-running `build_vm.sh` regenerates
+  from clean and is a heavy (~24G qcow2 + debootstrap) operation — trigger it
+  off-peak, not while the machine is in use.
 - `cube-resume-pointer.service` is REAL (wired 2026-08-13): a oneshot that writes
   the OS's "where to look to continue" into the cube at `c200/z011/y001/x001`
   (last snapshot index + resume coordinate). Was a dead stub before (unit pointed