[binlecode]

Summary

get_native_processes() was returning proc_pidinfo's pti_total_user/pti_total_system fields as if they were nanoseconds. They are mach absolute-clock ticks, not ns. On Apple Silicon the timebase is 125/3 (1 tick = 41.667 ns), so every process's CPU% read ~2.4% of its real value (1.2 s of burned CPU appeared as 0.03 s). Intel's 1/1 timebase made the raw values coincide with ns, which is why the offset-verified struct never surfaced the unit.

• actop/native_sys.py: read mach_timebase_info once at module load; _mach_ticks_to_ns() converts with integer math; cpu_time_ns now uses it.
• tests/test_native_sys.py: new test_cpu_time_ns_is_nanoseconds_not_mach_ticks — burns ~1.2 s CPU and asserts the native delta ≥ 60% of the getrusage delta. Reverting the fix drops it to ~2.4%, so the test is load-bearing. The share-based process-power tests cannot catch this (numerator and denominator shrink together).
• Version bump 1.6.3 → 1.6.4 + CHANGELOG.

Impact

• Fixes the absolute cpu_percent value (previously understated 41.67x on every Apple Silicon machine).
• cpu_time_share and watt attribution are ratio-based and were never affected.

Validation

• .venv/bin/ruff check --fix . / .venv/bin/ruff format . clean.
• .venv/bin/pytest -q -m "not local" → 91 passed.
• .venv/bin/pytest -q -m local → 48 passed (one re-run had a single flaky Textual #loading-splash mount-timing failure under load, not related to this change; passed on re-run).
• Manual probe on macOS (Apple Silicon, timebase 125/3): burned 1.2 s CPU → getrusage records 1.2 s, native cpu_time_ns delta now matches (~99.4–100%); before the fix it read ~0.03 s.
• Reference: Apple OpenRadar FB9546856; htop Platform_machTicksToNanoseconds.