Add Jira and Linear Ticket backends

[maxBRT]

Goal

Ship should support tracking systems beyond GitHub issues. The blog post calls out Jira and Linear as the next obvious targets.

Today Ship's Ticket model is backed by GitHub through internal/ticket/github.go. The intent is to make Ticket source and state transitions pluggable enough that a Run can be driven from another tracker.

Why

Different teams plan work in different systems. Ship should not require moving Tickets into GitHub issues just to run the implement, review, and final loop.

Initial scope

Add support for at least one non-GitHub tracker, with an architecture that can also fit the other.

Candidate trackers:

• Jira
• Linear

This does not need to be fully designed in this issue yet. The important commitment is that Ship should grow from a GitHub-only Ticket port into a tracker-agnostic system.

Questions to answer during planning

• What does the common Ticket interface need beyond number and title?
• How should Ticket body/spec content be fetched for non-GitHub systems?
• How should Ship represent Ticket identity when it is not a GitHub issue number?
• How should labels or statuses map to Ship concepts like ship, Done, Abort, and Partial Progress?
• Should the tracker be selected in .ship/config.yaml?
• How should credentials and auth errors be surfaced?

Possible implementation direction

• Keep ticket.Port as the seam, but make the concrete implementation configurable.
• Add tracker config to .ship/config.yaml.
• Add adapters such as internal/ticket/linear.go and internal/ticket/jira.go.
• Keep GitHub as the default behavior for current users.

Acceptance sketch

• A user can configure Ship to read candidate Tickets from at least one new tracker.
• Ship can mark completed work Done in that tracker.
• Abort leaves unfinished Tickets eligible for a later Run.
• Existing GitHub behavior continues to work.