feat: issues find-branch command to find issue by Git branch name

[lightstrike]

Summary

• Add execute_optional method to SDK Client for nullable GraphQL return types, refactor execute to delegate to it — Removed: execute::<Option<T>> already handles nullable responses via serde's Option deserialization, no new method needed
• Add issueVcsBranchSearch query to operations.toml and regenerate SDK
• New CLI subcommand: lineark issues find-branch <BRANCH> — finds the Linear issue associated with a Git branch name
• Returns full issue detail (same as issues read) on match, exits non-zero with "No issue found" on no match
• Update lineark usage reference

Test plan

• cargo fmt --check — clean
• cargo clippy --workspace -- -D warnings — clean
• cargo test --workspace — all offline tests pass
• CLI online tests pass
• Manual smoke: lineark issues find-branch <branch> works, no-match exits non-zero
• Merged origin/main to resolve conflicts

[flipbit03]

Hey @lightstrike, nice feature — find-branch is a great addition! A few notes on the implementation:

execute_optional isn't needed — the existing execute method already handles this case through Rust's type system. When the API returns {"data": {"issueVcsBranchSearch": null}}:

1. data.get(data_path) returns Some(&Value::Null) (the key exists, it's just null)
2. serde_json::from_value::<Option<T>>(Value::Null) deserializes to Ok(None)

So the caller just needs to request Option<T> as the type parameter:

let result: Option<IssueDetail> = client
    .execute(&query, variables, "issueVcsBranchSearch")
    .await?;

No new SDK method required — serde's Option deserialization already does exactly what execute_optional does manually. It's worth keeping in mind that when you feel like you need to add a new code path for nullability, check whether the type system already handles it for you. Rust + serde are really good at this!

I've pushed a fix to your branch removing execute_optional and using execute::<Option<T>> directly. Also merged latest origin/main to resolve conflicts.

[flipbit03]

Note: This PR currently hand-rolls the GraphQL query for issueVcsBranchSearch because the generated SDK function can't handle nullable return types (see #120). Once #120 lands (blanket impl<T: GraphQLFields> GraphQLFields for Option<T>), the CLI handler and SDK tests should be updated to use the generated client.issue_vcs_branch_search::<Option<IssueDetail>>() directly instead of raw client.execute().

Blocked by #120.

[flipbit03]

Hey @lightstrike — pushed a final round of changes to your branch.

Your find-branch implementation exposed a real gap in the SDK: nullable GraphQL fields (like issueVcsBranchSearch: Issue without !) couldn't use generated functions because Option<T> didn't implement GraphQLFields. We fixed this properly in #120 with a blanket impl + codegen nullable support.

With that merged, this PR now uses the generated client.issue_vcs_branch_search() instead of hand-rolling the query. Also cleaned up: UUID suffixes on SDK test names, removed redundant manual issue_delete (RAII guard handles it), reordered FindBranch enum variant.

Thanks for the contribution that sparked a real SDK improvement!

[flipbit03]

LGTM!