fix(daemon): differentiate multi-profile state in status output (#1575)

[Chen17-sq]

Linked issue

Closes #1575.

Summary

opencli daemon status rendered the line Extension: disconnected for three structurally different states:

1. zero profiles connected — accurate "disconnected"
2. 2+ profiles connected, no default selected — misleading
3. requested profile vanished mid-session — misleading

Users hitting case 2 (a common setup: work + personal Chrome profiles both running with the OpenCLI extension installed) read "disconnected" and start reinstalling extensions / restarting Chrome / restarting the daemon — when the actual one-command fix is opencli profile use <name>.

The daemon JSON has carried profileRequired / profileDisconnected flags for a while (see daemon.ts:259-260). This PR teaches the CLI formatter to mirror that distinction.

Implementation

src/commands/daemon.ts:

• Extracted formatExtensionLabel(status: DaemonStatus): string (exported for direct unit testing).
• Renders one of four states:
  • connected (vX.Y.Z) — single profile selected, extension OK (unchanged).
  • N profile(s) connected, none selected — run \opencli profile use `` — covers the 2+ profile no-default case AND the single-orphan-profile case where the user hasn't picked one yet. Grammar adjusts on count.
  • requested profile not connected — open that Chrome profile, or pick another with \opencli profile use `— coversprofileDisconnected`.
  • disconnected — true zero-profile case (unchanged).

Imported DaemonStatus type from daemon-client.js to type the helper signature.

The JSON payload does not change. The CLI text is the only user-visible surface that needed the three-state distinction.

Why this matters

A new user with a work + personal Chrome profile setup runs opencli daemon status, sees "Extension: disconnected", and goes down the reinstall-everything debug path. With this change they instead see:

Extension: 2 profiles connected, none selected — run `opencli profile use <name>`
Profiles: work v1.0.14, personal v1.0.14

— which is both diagnostic AND actionable in a single line.

Test plan

Added two describe blocks to src/commands/daemon.test.ts:

• formatExtensionLabel — multi-profile state differentiation — covers all four label branches plus singular/plural grammar at the 1-profile-no-default edge.
• daemonStatus output for issue #1575 fix — asserts the end-to-end formatter never emits the bare Extension: disconnected line in the 2-profiles-no-default case, and that the Profiles: follow-up line still lists both profile names.

Local test run

npx vitest run src/commands/daemon.test.ts
 Test Files  1 passed (1)
      Tests  16 passed (16)

5 new tests; 11 pre-existing tests still pass.

Checklist

• CLI text only — no breaking changes to JSON payload or to getDaemonHealth() state machine.
• Singular/plural grammar handled.
• Existing tests pass.
• New regression tests added.

[Chen17-sq]

Self-review: tightened the patch.

• Inlined the label logic back into daemonStatus() — no more exported formatExtensionLabel helper. The function was 8 lines; pulling it out as a named API was over-engineering for what's effectively a single 4-branch if/else.
• Dropped one of the two test describe blocks. All four state branches are still covered, but only via the public daemonStatus() output (which is what users actually see).
• Simplified the profileDisconnected message to match the profileRequired voice (run \opencli profile use `` in both cases).

Diff went from +148/-7 to +91/-3. Test count went from 16 to 14 (4 state-coverage tests + 10 pre-existing).