feat(tracker): multi-provider issue intake (GitHub, Linear, Jira)

[anirudh5harma]

Summary

Registered projects can now opt into issue-driven intake against GitHub, Linear, or Jira. The daemon polls explicitly eligible open issues for each project's configured provider and starts one worker session per issue, preserving the canonical <provider>:<native> issue identifier so restarts cannot create duplicates. Existing projects remain unaffected until intake is enabled with a label or assignee rule; tracker or spawn failures back off per-project without blocking the daemon.

Closes #2282. This builds on the original GitHub-only port of aoagents/ReverbCode#424 and extends it to two more providers behind the same observer.

What this PR adds

• Linear adapter (backend/internal/adapters/tracker/linear/) — GraphQL client, team-key scope, state mapping backlog/unstarted/triage→open, started→in_progress, completed→done, cancelled→cancelled. Credentials from AO_LINEAR_TOKEN (with LINEAR_API_KEY fallback).
• Jira adapter (backend/internal/adapters/tracker/jira/) — REST + JQL client, project-key + tenant base-URL scope, status-category mapping plus "Cancelled" / "Won't Do" name heuristics, ADF description flattening. Credentials from AO_JIRA_EMAIL + AO_JIRA_TOKEN Basic auth.
• Domain extension — TrackerProviderLinear, TrackerProviderJira, and provider-specific scope fields on TrackerIntakeConfig (Team for Linear; BaseURL + ProjectKey for Jira; Repo stays GitHub-only). Per-provider Validate() rejects cross-provider field bleed so a stale Team cannot survive a switch back to GitHub.
• Observer router — TrackerResolver interface dispatches each project's poll to the right adapter. The daemon wires a multiTrackerResolver with three lazy adapters; providers a project doesn't configure pay no auth or network cost. seen deduplication is now keyed by the canonical <provider>:<native> form so Linear ENG-1 and Jira ENG-1 don't collide.
• OpenAPI + TS schema regen — TrackerIntakeConfig picks up team, baseURL, projectKey, and the github | linear | jira enum.

Design notes

• Intake remains read-only toward every tracker (no comments, no transitions).
• Credentials are env vars only, global per provider. One Linear token, one Jira account, shared across all projects. No SQLite secret store, no OS keychain.
• Per-project config holds the scope only (team key / repo / project key + site URL), never credentials.
• Linear's URL field is taken straight from its GraphQL response so workspace-slug guessing isn't needed.
• Jira's TrackerRepo.BaseURL carries the tenant site per-call so a single adapter instance can serve multiple Jira tenants.
• GitHub keeps the existing AO_GITHUB_TOKEN + gh auth token precedence and 5-minute token cache.

Validation

• cd backend && go build ./...
• cd backend && go vet ./...
• go test -race ./internal/observe/trackerintake/... ./internal/adapters/tracker/... ./internal/domain/... — all green
• New unit tests:
  • linear/tracker_test.go — list filter shape, assignee wildcard pass-through, Get happy path / not-found, unauthorized → ErrAuthFailed, wrong-provider routing
  • jira/tracker_test.go — JQL composition incl. quote escaping, base-URL normalization, Cancelled/Won't Do mapping, ADF flatten, wrong-provider routing
  • domain/projectconfig_test.go — per-provider Validate rows incl. cross-provider field bleed
  • observe/trackerintake/observer_test.go — three-project multi-provider poll asserts each adapter receives its own scope and no IDs collide
• npm run api
• npm run frontend:typecheck

go test ./... still hits the pre-existing duplicate migration version 20 panic on main (0020_review_run_unique_pr_sha.sql + 0020_pr_reviews.sql); this PR does not touch migrations.

Post-deploy monitoring

For the first enabled project per provider, watch tracker intake log lines and confirm one eligible issue creates one worker session carrying the canonical <provider>:<native> id. Healthy signals: no repeated spawn after a second poll or daemon restart; no polling for projects with intake disabled; tracker intake disabled: no usable … warnings if a provider's env vars are missing. Rollback trigger: repeated spawn attempts for the same issue, broad intake without explicit rules, or daemon-startup degradation; the immediate mitigation is unsetting trackerIntake.enabled per project.