[Feature]: Link threads to issues and auto-settle when the issue closes

[dortort]

Problem

Threads can already link to a pull request and settle themselves when it merges or closes. A lot of work starts from a ticket rather than a PR, though: a GitHub/GitLab issue, a Jira ticket, a Linear issue. Today that thread stays in the active list after the ticket is done unless someone settles it by hand, and nothing in the thread shows the ticket's state.

Adjacent asks already in Ideas: #8334 (name threads from linked tickets), #6752 (import Linear issues), #7056 (start worktrees from a Linear issue), #6833 (separate settle toggles). This proposal is the piece those all lean on: a thread that knows which issue it is about.

Proposal

• Link a thread to an issue, manually (paste a URL in the palette or the linked-work panel, right-click an issue link in the conversation) or from an agent (MCP link_issue / unlink_issue / list_linked_issues).
• Show the issue's title and open/closed state on the thread, and include its identifier in thread search.
• Auto-settle the thread when the issue closes, behind a setting (sidebarAutoSettleOnIssueClose, default on, per-project override) that sits next to the existing merge/inactivity settings.
• Providers: GitHub, GitLab, Forgejo, and Azure DevOps issues through the CLIs the app already uses for pull requests; Jira and Linear through API tokens configured under Settings, redacted before they reach a client.

How it fits the existing design

• A sibling ThreadIssueLink beside ThreadPullRequestLink, not a generalised "work item". The PR link's shape (branches, checks, stacks, merged) is load-bearing across every host adapter and both clients; issues have an open | closed lifecycle and, for Jira/Linear, no repository at all.
• Links are resolved server-side at link time to a durable identity (Jira's numeric id, Linear's UUID, org-scoped Azure work-item ids, repo + number for the git hosts) with the display key kept separately, so key changes and repository transfers do not break the link.
• An issue sync reactor mirrors the PR sync reactor: one-minute sweep, grouped by issue so a host is asked once per issue, writes only on change, batch reads for Jira, Azure and Linear (one request per tracker per sweep), read failures surfaced on the link with retry and unlink instead of an endless unsynced state.
• Settlement reuses thread.auto-settle unchanged. The policy separates "which triggers participate" from "does the sweep run", so turning issue settlement on cannot re-arm PR-close settlement for anyone who had merge and inactivity settlement off. Any open linked item (PR or issue) blocks settlement; an open PR on the thread's branch still vetoes issue-driven settlement; an issue with an unknown close time never settles a thread on its own.
• Repo-host issues route through a project on that host for credentials and rate limiting, exactly as PR reads do. Jira and Linear route through the verified tracker config.
• Outbound polling only. No webhooks, so nothing changes for remote, relay or tunnel setups.

Surfaces

Web and desktop: link, unlink, refresh, linked-work panel, palette, autolink, status indicator, settings (flag plus an Issue trackers panel for Jira/Linear). Mobile: linked-issue display with open-in-browser and the settle toggle, synced across environments like the existing auto-settle settings. Docs: a Linked issues section beside Linked pull requests, one sentence in the sidebar guide.

Out of scope

Bitbucket issues (the Cloud tracker is legacy), Atlassian scoped/OAuth tokens, following GitLab issue moves automatically, inbound webhooks, and linking or secret entry from mobile.

Status

Implemented in a fork; I will add the PR link here once it is up. Very happy to shrink, split, or drop this if it is not a direction you want.

[Jardo-51]

Just a note on the issue links: The link should be displayed in the open thread under the composer, next to the PR link (there is plenty of space). But it should also be displayed in the sidebar. The sidebar usually doesn't have enough space to show the issue and the PR link side by side. So there should be a setting where the user can choose whether they want to see the PR link or the issue link in the sidebar.Or potentially both, if they have a wide-enough sidebar.