[Feature]: Name new threads from linked tickets

[matheustimbo]

Problem

When a new thread starts from a ticket URL, its generated title often paraphrases the prompt instead of using the ticket title and identifier users already recognize. That makes ticket-driven workflows harder to scan and search.

Proposed solution

On the first user message only, detect exactly one canonical issue/work-item link and resolve its metadata asynchronously on the T3 server. Keep the current provisional/generated title while resolving, then apply the ticket title if the user has not manually renamed or regenerated the thread.

The server is the right boundary because credentials and local CLIs live with the environment and web, desktop, and mobile all converge there.

Initial drivers:

• GitHub Issues
• GitLab Issues
• Azure DevOps work items
• Bitbucket Cloud issues
• Jira Cloud/Data Center
• ClickUp tasks

Use local authenticated tools where they allow deterministic account selection (gh, glab, az) and explicit REST connections otherwise. Model ticket integrations as a small registry of drivers and instances, conceptually similar to agent provider instances but separate from agent sessions and model selection.

User controls

• Enabled by default with opt-out
• Global policy per environment with project override
• Formats: title, identifier plus title, disabled, or a small custom template
• Project-to-instance bindings for users with multiple accounts on the same host
• Settings UI and connection status on web, desktop, and mobile

Safety and behavior

• Never fetch arbitrary prompt URLs; only canonical patterns matched to authenticated/configured instances
• Exactly one unique ticket link is required; multiple tickets fall back to current title generation
• Ignore links in code and blockquotes
• Ten-second timeout, no retry, silent fallback
• Manual rename, explicit regeneration, or settings changes always win over pending lookups
• Snapshot once at thread creation; no polling
• Secrets remain server-side and redacted from clients

Smallest useful contribution

I plan to keep the implementation modular and test the URL parser, provider routing, account binding, async title precedence, and fallback behavior through focused seams. Because this crosses contracts, server orchestration, and settings surfaces, I am happy to split the contribution into maintainer-preferred slices if that makes review easier.

Related title discussions: #7298 and #6836.

[matheustimbo]

Implementation is ready for review on the fork branch:

https://github.com/matheustimbo/t3code/tree/feat/ticket-thread-titles

Validation: all six affected packages pass typecheck, 232 focused tests pass, and modified-file lint is clean apart from two pre-existing warnings. The complete implementation covers server, web/desktop, and mobile, so it is about 3.5k changed lines. I deliberately have not opened an XXL PR because CONTRIBUTING.md explicitly asks external contributors to keep PRs below that scale.

Would you prefer this split into: (1) the first-message title/CAS flow with GitHub Issues, (2) the remaining ticket drivers and account routing, and (3) settings/project bindings across clients? I am happy to reshape it to whatever review boundary you prefer.

[matheustimbo]

Full implementation PR: #8344