Fix two GraphQL selections that Linear's schema no longer accepts

[philipbjorge]

Two commands return HTTP 400 for every caller against the current Linear schema. Both are one-field fixes.

initiatives list

$ linear-cli initiatives list -o json --compact
Cannot query field "progress" on type "Initiative". Did you mean "projects"?

Introspecting the live schema, Initiative has 49 fields and progress is not among them — it carries health and status instead. Linear appears to have removed it. This selects health and shows it in the table where the derived percentage used to go.

Deliberately left alone:

• initiative get never selected the field, so it was never broken.
• The progress selection on Project, inside the initiative's projects query, is still valid — Project does expose progress.

issues get --history

$ linear-cli issues get ENG-843 --history -o json --compact --fields identifier
Cannot query field "slaBreachesAt" on type "IssueHistory".
Did you mean "toSlaBreachesAt", "fromSlaBreachesAt", or "toSlaBreached"?

IssueHistory only carries the to*/from* prefixed variants. This drops the two bare selections from the history fragment. The identically named fields on the Issue type are valid and stay, as does the formatter that reads them.

This is the same class of bug as #29, which you fixed in 0.3.26.

Also included

A one-line chore commit removing a trailing blank line from initiatives.rs. It is the only formatting diff in the tree, and PR Check has been failing on "Check formatting" since 2026-08-05 because of it — so without it this PR shows red through no fault of its own. Happy to split it out if you would rather take it separately.

Verification

Run against a live workspace on macOS arm64, and all three commands now return data:

cargo fmt --check                                        # clean
cargo clippy --release --features secure-storage -- -D warnings   # clean
cargo test --release --features secure-storage           # 352 passed, 203 passed

Context

We drive linear-cli from an agent harness, and these two accounted for 78 failed invocations in a single week — they are the top two failure modes in our logs. Thanks for the tool.