bullpen sessions: add --json for scripting

[Steel-tech]

bullpen sessions prints fixed-width human output and nothing else — there is no machine-readable output anywhere in the CLI today. Anything that wants to act on session state has to parse a padded column layout, which breaks the moment a title contains two spaces or an id prefix collides.

That is an awkward gap for a harness whose stated thesis is that SQLite is the coordination plane. Reading that plane from outside bullpen currently means either screen-scraping or opening the database directly, and the second one couples callers to the schema.

What

Add --json to bullpen sessions. When set, emit the session list as JSON instead of the human table.

Each session should carry at least what the human output already shows, unabbreviated: full session id (not the 8-char prefix), updated_at, provider, input and output token counts, title, and parent_session_id for pen children.

Notes

• Additive only — default output is unchanged, so nothing that reads the current format breaks.
• The empty case currently prints a friendly "no sessions yet" hint. Under --json that should be valid JSON (an empty array), not prose on stdout.
• serde and serde_json are already workspace dependencies.

[Steel-tech]

Shipped in 2089a64 (#6).

bullpen sessions --json emits a JSON array of the full session records — full uuid rather than the 8-char prefix the table shows, plus status and pid, which the human table never exposed. parent_session_id is null for top-level sessions instead of the table's └ child of … marker. Default output is unchanged byte-for-byte.

The empty case returns [] with exit 0, and the prose hint is suppressed in JSON mode — verified live against an empty store, and pinned by a unit test so it cannot regress.

Serialization lives in a pure helper in the CLI rather than a Serialize derive on bullpen_store::Session, deliberately: the store struct is internal state, and deriving on it would make any future field rename a silent breaking change to the CLI's wire output.

One non-defect note for anyone consuming this: serde_json::json! without preserve_order emits object keys alphabetically, so the field order is created_at, cwd, id, model, … rather than declaration order. JSON object order carries no meaning — don't depend on it.