daemon: --ttl 0 is dropped by the background launcher, and daemon status reports a TTL the daemon doesn't have #4238

Version: ruflo / @claude-flow/cli 3.53.0 and 3.56.10 (same code in both), Linux, Node 22

Bug 1: daemon start --ttl 0 runs with the 12h default

parser.parseValue turns every numeric-looking value into a number, even for options declared type: 'string', so ctx.flags.ttl is 0 (a number). startBackgroundDaemon then forwards the TTL only when it is a string:

// commands/daemon.js
if (typeof ttl === 'string' && /^\d+$/.test(ttl)) {
    forkArgs.push('--ttl', ttl);
}

The forked daemon start --foreground gets no --ttl and falls back to DEFAULT_DAEMON_TTL_MS (12h). Any numeric TTL is affected, not just 0.

Repro: ruflo daemon start --ttl 0 -Q, then ps -eo args | grep '[d]aemon start'. The child's argv has no --ttl.

Fix: String(ttl) before the check, or make parseValue honour the option's declared type.

Bug 2: daemon status prints the status process's default config

daemon status (around line 1170/1201) calls getDaemon(projectRoot), which builds a fresh WorkerDaemon in the status process, and prints its config.ttlMs. A daemon started with TTL off still shows TTL: 12h (self-shutdown). daemon status --all reads daemon-state.json and reports the real ttlMs.

Repro: start the daemon in the foreground with --ttl 0. .claude-flow/daemon-state.json has "ttlMs": 0, but ruflo daemon status prints TTL: 12h.

Fix: in status, read config.ttlMs from daemon-state.json, as --all already does.

Workaround in use: start ruflo daemon start --foreground --ttl 0 … under setsid nohup yourself.