feat(tracker): bind GitHub intake to user and labels

[anirudh5harma]

Summary

GitHub issue intake is now bound to the authenticated GitHub account, supports repository-native label filters, and previews the number of issues that match before settings are saved. This removes the broad * assignee mode and makes intake scope visible and trustable without moving GitHub logic into Electron.

Related: #2325

What this adds

Backend

• Resolves the active login through GitHub's GET /user endpoint and uses it for every intake poll; the user is no longer configurable in project state.
• Fetches the complete repository label catalog through GET /repos/{owner}/{repo}/labels, including pagination, names, colors, and descriptions.
• Keeps label catalogs fresh with a five-minute service cache, page-aware ETag revalidation in the GitHub adapter, and an explicit refresh path.
• Persists selected label names in the existing JSON-backed TrackerIntakeConfig; no SQLite migration is required. Multiple labels use AND semantics, while an empty selection means all eligible open issues assigned to the authenticated user.
• Adds a side-effect-free preview endpoint that counts issues through the same repository, user, state, and label matching rules used by the intake observer.
• Regenerates the OpenAPI contract and frontend schema from the code-first controller DTOs.

Frontend

• Shows the repository and authenticated assignee as compact GitHub links in a 50/50 settings row.
• Adds a searchable, multi-select label popover with repository colors, descriptions, missing-label handling, and manual refresh.
• Shows the matching open-issue count inline in a highlighted badge and refreshes it as label selections change.
• Keeps project creation compact: intake is still opt-in and displays the authenticated account without exposing provider credentials or configuration.

Design notes

• GitHub remains the only provider in this scope; no Linear or Jira behavior is introduced.
• Label fetching and previewing stay daemon-owned. The Electron frontend only calls typed loopback API routes.
• Existing v1 configs remain readable. The removed assignee JSON field is ignored, and enabled intake binds to the account currently authenticated with GitHub.
• Intake remains read-only toward GitHub and retains the existing durable issue/session deduplication behavior.

Validation

• npm run frontend:typecheck
• npm --prefix frontend test — 49 files, 475 tests passed
• cd frontend && npx vite build --config vite.renderer.config.ts
• cd backend && GOTOOLCHAIN=go1.25.7 go build ./... && GOTOOLCHAIN=go1.25.7 go vet ./...
• Focused Go suites for tracker adapter, observer, service, controllers, API spec, domain, and shared intake matching — all passed
• npm run api with no generated OpenAPI or TypeScript schema drift
• golangci-lint v2.12.2 — 0 issues
• npm run lint reaches the unchanged kilocode interactive-shell test and times out at TestAuthStatusUnknownWhenKeyOnlyComesFromInteractiveShell; all intake packages pass, and the linter was run separately above.

Post-Deploy Monitoring & Validation

• Search daemon logs for tracker intake: resolve authenticated user failed, tracker intake: list issues failed, GITHUB_LABELS_FAILED, and GITHUB_PREVIEW_FAILED.
• Healthy signals: the settings identity matches gh auth, repository labels load or revalidate without exhausting rate limits, preview counts match the observer's eligible set, and repeated polls do not create duplicate sessions.
• Failure signals: intake polling the wrong assignee, selected labels being ignored, repeated GitHub API failures, or a preview count that diverges from spawned sessions. Immediate mitigation is disabling trackerIntake.enabled for the affected project; roll back if the behavior reproduces across repositories.
• Validation window: first week after release; owner: Agent Orchestrator maintainers.

---