fix(cli): make sonilo whoami answerable, in both directions

[spencer-zqian]

Two bugs that compound into one: whoami could not be used to answer "am I signed in", and its output said the wrong thing when you were.

Exit code

whoami returned 0 whether or not a credential existed — it printed Not signed in. Run sonilo login. and then exited successfully. Anything branching on it took the signed-in path with nothing on disk, and only found out when the next command failed on auth.

	signed in	not signed in
sonilo whoami (before)	0	0
sonilo whoami (after)	0	1
sonilo account	0	1

gh auth status sets the precedent: a status command that cannot be branched on is not a status command.

An expired credential still exits 0. It names a real account, the line already says (expired), and sonilo login is the fix — reporting "not signed in" would send callers to first-time setup instead.

Blank account name

accountLabel was account_name ?? account_id, and the API returns account_name: " " for an account with no display name set. A single space is neither null nor undefined, so it won, and whoami printed:

account:
key: sk-47060...
expires: 2026-11-11

That empty line is indistinguishable from a credential that never loaded.

How this surfaced

Found while testing the skills repo's transport routing, whose CLI branch is gated on this command ("sonilo whoami exits 0 → use the CLI").

Both bugs are verified directly and independently of any agent behaviour — the exit-code table above and the " " account name are reproducible from a shell in one command each. That is what this PR rests on.

One agent run did misread the blank account: line against a fully authenticated CLI and conclude nothing was set up. I initially wrote that up as "reproduced 2/2"; a later controlled comparison showed that was overstated — the second run had failed for an unrelated reason (Bash was not permitted in that non-interactive session), and with permissions held constant the misread did not reproduce every time. The behavioural evidence is one real occurrence, not a consistent failure. The exit-code defect needs no behavioural evidence at all: a probe that returns 0 in both states carries no information by construction.

Notes

runWhoami returns a boolean instead of setting process.exitCode itself — the tests call it directly, and setting the exit code there would leave the whole vitest run at 1.

Verification

• 157 tests pass (6 files); tsc --noEmit clean.
• Built and run against a real credential — the account id now prints where the blank was, exit 0.
• Built and run against an empty HOME — Not signed in, exit 1.
• New tests cover the boolean in all four states (none / stored / env key / expired) and the blank-name fallback across " ", "", " ", and null.

🤖 Generated with Claude Code

[sapient-app]

Lightsage docs evals

Waiting for the staging docs URL before running evals.

Lightsage will start the selected PR evals automatically when GitHub reports a successful docs deployment for this PR. This usually happens within 15 minutes.

Commit: 8f3ff6e
Status: waiting for staging docs URL