fix(cli): make grob stop recognise its daemon on macOS

[Destynova2]

The bug

On macOS, grob stop refused to stop its own running daemon:

❌ Failed to stop service (PID: 41257): refusing to stop PID 41257: not a running Grob process

…and grob start -d (restart) silently left the old daemon running, so a
restart never actually took effect.

Cause

command_invokes_grob (the PID-identity guard) split the process command line
only on NUL. That matches Linux /proc/<pid>/cmdline (grob\0start\0) but not
macOS ps -o command=, which is space-separated:

/opt/homebrew/bin/grob start

With no NUL, the whole string reached Path::file_name, giving "grob start"
(≠ "grob"). So is_process_running returned false for a live daemon, and both
grob stop and the restart path in grob start refused to act.

Reproduced:

executable = "grob start"  → == "grob" ? false

Fix

Pick the separator by which one is present — NUL when the string contains it
(Linux), whitespace otherwise (macOS):

let first_arg = if command.contains('\0') {
    command.split('\0').next()
} else {
    command.split_whitespace().next()
} …

All existing negative cases still hold (grob-upgrade, python …/grob.py,
agrob-helper).

Verification

• Unit tests: added command_identity_accepts_space_separated_macos_form
  (the exact ps string); existing test still green.
• End to end on macOS: a daemon started with the fixed binary is now stopped by
  grob stop → ✅ Service stopped successfully (was refusing to stop).

Note (single-daemon model)

The pid file is a single global ~/.grob/grob.pid. With identity now working,
grob start on any port stops whatever that file points at — so a second daemon
on another port replaces the first. That's consistent with the one-daemon
design; a port-scoped pid file would be a separate change if parallel daemons
are ever wanted.

🤖 Generated with Claude Code